Let's say my Server
is both Authorization Server
and Resource server
My Client (for example mobile app) can authenticate in 2 matters:
- via Resource Owner Password Credentials Grant
- via Authorization Code Grant / Implicit using facebook for example
Now 1 is trivial - I'm just storing the access toke
n in the server DB after authentication and on each call to protected resource
I'm verifying the access token.
But what about case 2: should my server store the access token
I got from facebook or on each call for protected resource my server should call facebook api
in order to validate the access token
?
Are there any drawbacks to keeping an access token which your system didn't generate?
Assumptions:
- access tokens have ttl
- access tokens are only used to get protected resources from my Resource Server (not facebook for example)
-
I'd go for the latter approach, since the token is being given to the user they should really present all tokens on request. You don't really want to be responsible for storing session tokens that aren't for your API. I'm wondering why you're verifying access to facebook through your API at all, should that not be done by the users device, is there anything that specifically needs to be routed through your servers?Elliot Blackburn– Elliot Blackburn02/04/2015 16:02:19Commented Feb 4, 2015 at 16:02
-
1I guess I wasn't clear, the resource server is mine. I'm just giving the user the option to authenticate with my authorisation server or Facebook with server. The token is for my apiroyB– royB02/04/2015 16:05:31Commented Feb 4, 2015 at 16:05
-
I would store the token yourself after they've authenticated with Facebook if that's the case. You've authorized that they are who they said they are, and you now have a token to prove that authentication. As long as your timeouts are correct and match Facebook properly, I'd say the first approach is the easiest and still secure.Elliot Blackburn– Elliot Blackburn02/04/2015 16:10:07Commented Feb 4, 2015 at 16:10