OAuthv2 authorization grants

Question

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?

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.