Let's say my Server is both Authorization Server and Resource server

My Client (for example mobile app) can authenticate in 2 matters:

  1. via Resource Owner Password Credentials Grant
  2. via Authorization Code Grant / Implicit using facebook for example

Now 1 is trivial - I'm just storing the access token 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?


  1. access tokens have ttl
  2. 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? Feb 4 '15 at 16:02
  • 1
    I 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 api
    – royB
    Feb 4 '15 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. Feb 4 '15 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.