Does an authorization code grant rely on sessions?

Question

It's my (possibly flawed) understanding that the authorisation code grant is attractive because it keeps access tokens away from a potentially insecure user agent. I understand how this would work with the initial call:

• The (insecure) user agent gets a code from the auth server
• The agent then hands the code to the (secure) client application.
• The client application can then exchange it for access/id/refresh tokens.

All good so far. But now the user agent makes a 2nd request. How does that request get linked with the token(s) from the initial call?

• It could go back and get another auth code, but this seems impractical.
• It can't use the same code again as they're single use.
• It doesn't have any of the tokens itself (as they're nice and safe on our app server).
• So that leaves me with sessions. I.e. The app server matches the HTTP session with the tokens.

Can someone confirm or correct this assumption? While the initial call is well documented, I can't find much in the way of what happens on subsequent calls. Any links to the actual mechanism would be appreciated!

Edit (to add context)

I am interested in securing a single page application calling an API. In the past I used an implicit grant for such interactions (with the access token being sent from the browser on every API call). However, given that the implicit grant is no longer consider to be secure I would like to switch to an authorization code grant.

So my question is: After the initial authentication, what goes out on each subsequent API call for authentication?

• A token?
• A session cookie?
• Something else?

Answer 1

After the initial authentication, what goes out on each subsequent API call for authentication?

For API's:

• Each successive API call would use a token (Access token). You would be using https://oauth.net/2/grant-types/client-credentials/ (API/Resource focus)
• Access is constrained by scope and linked to the Access Token. This prevents calls to unapproved API's for a given token (https://oauth.net/2/scope/)

For webapps:

• You would likely use https://oauth.net/2/grant-types/authorization-code/
• You are correct when you say you would set up a session using something like a cookie to identify the user.

On a previous project we used Auth0 (I am not in any way affiliated). They have some sample apps - https://auth0.com/docs/quickstarts . I use Java primarily, so I have linked those as well. It is also free to sign up and play around:

• API > https://auth0.com/docs/quickstart/backend/java-spring-security
• Webapp > https://auth0.com/docs/quickstart/webapp/java-spring-security-mvc
• SPA > https://auth0.com/docs/quickstart/spa/vanillajs

Hope this helps?

Answer 2

I'm no expert here, but my understanding from reading RFC 6749 is that the point of the authorization code grant is to allow

the client [to] requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

The RFC continues with this example:

an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service.

Basically, once the client (in this case a 3rd-party service) gets the authorization code, it exchanges that code for a pair of tokens (access tokens and refresh tokens) via an authorization server.

The client then uses the access token to access the protected resources, and refresh tokens to gain new access tokens over time. The client no longer requires an authorization code -- as it uses these tokens for continued access to the protected resources.

Access tokens typically expire after some minutes, but refresh tokens generally last much longer and can be used at any time to get a new pair (resource + access) of tokens -- hence continued access!

I'm unsure what you mean by "user agent makes a 2nd request", the end-user/resource owner doesn't need to make any new requests, and the client/3rd-party now uses tokens for continued access to the protected resources. The authorization code is a one-time use code, to pass between end-user and client, and from then on can be discarded.

To disconnect(logout) a client from the protected resource -- the end-user has to inform the authorization server, which can then stop issuing new tokens to the client, or revoke the tokens already issued to the client (if possible).