I just read this excellent tutorial on OAuthv2 but am still missing some important concepts regarding authorization grants.

I'm fundamentally not understanding the necessity for the two request/response cycles between client app and authorization server, where:

  • First the user is redirected to the auth server during an Authorization Request, whereby (on successful authentication), they receive an auth code; and then
  • Next, the client app makes a second Token Request to the auth server, whereby the auth server validates the client's ID, secret and auth code, and sends back an access token for it to use

Auth codes vs. access tokens

What is the difference between this "auth code" and this "access token"? Why do I need to first generate an auth code so that I can, subsequently, obtain an access token?!? Why not just do all this in 1 roundtrip and get an access token upon successful authentication?

Access tokens and resource servers

I assume that the main point of the access token is to act as a hall pass for future requests, so that client apps aren't re-authenticating each subsequent request. Ergo I assume that, with a valid access token, client apps can now "speak directly" with resource servers. And I assume that, upon receiving each request, the resource servers probably validate access tokens with their respective auth servers. Am I on track here or way off base?

Access tokens and SSO?

Can access tokens be used in an SSO scenario where you have multiple resource servers all using the same auth server? Meaning, once I authenticate with an auth server and receive my access token from it when I'm inside 1 SSO app, can I then migrate to another SSO app, and apply the same access token (assuming it hasn't expired yet) and be "signed in" to that second app, without having to re-authenticate?

  • As far as I recall, the authentication code is (as the name implies) for authentication. The access token, however, is for authorization. Commented Sep 12, 2015 at 6:04

1 Answer 1


Using the authorization code grant brings you two things that other grants are lacking.

  1. it gives you authentication of both the user and the client. It does client authentication by sending the client id and client secret when acquiring the access token.

  2. it keeps the access token hidden from the user agent (typically a browser), where they could be stolen much more easily.

The implicit grant actually does this all in one round trip and therefore exposes the access token to the user-agent and does not authenticate the client itself (only the user).

You are correct that a client can access the resources on the resource server using the access token without re-authenticating each request. The resource server does not need to communicate with the authorization server to validate the token as it uses digital signatures to trust the contents of the token.

Access tokens can be used in SSO scenarios, but typically your user-agent would go back to the authorization server to get another access token to talk to another resource server. Your user-agent would establish a session (likely cookies) with the authorization server to prevent re-authentication.

  • Thanks @user18044 (+1)! One quick followup about the SSO if you don't mind. You say that "Access tokens can be used in SSO scenarios, but typically your user-agent would go back to the auth server to get another access token...". This leads me to believe that my suggestion of re-using access tokens across all SSO-federated apps is less secure than what you are saying. Is that because, in my scenario, it would be easier for someone to hijack the "universal access token", instead of making them hijack 1 access token per SSO app?
    – smeeb
    Commented Sep 12, 2015 at 19:18
  • I guess I'm wonder what the security reasons are for 1 token per app. Thanks again!
    – smeeb
    Commented Sep 12, 2015 at 19:18
  • @smeeb, typically your access tokens also contain authorization info (what can the user do in the application or what roles he/she is in). This would differ per application, so you'd need different access tokens. You also might have users that have access to one application, but not the other.
    – MvdD
    Commented Sep 12, 2015 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.