First, there is a registered application that has consumer_key
and consumer_secret
.
When users authenticate and "allow" your registered application, you get back:
an access_token
that is considered the user's "password" and would allow JUST YOUR application to act on the user's behalf.
So, getting just the user's access_token
from your database won't help much if they don't also have the consumer_key
and consumer_secret
for complete access.
The service provider compares all 4 parameters on request. It would be smart to encrypt these 4 parameters before storage and decrypt them before response.
This is just when you need to update or make changes to the user's resource owner on behalf of a user. To keep a user logged-in on your site, use sessions.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…