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?

2 Answers 2


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

For API's:

For webapps:

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:

Hope this helps?


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).

  • Why would they not need to make a 2nd request? Typically web apps will generate a constant stream of API calls. On the first one the code/token exchange happens. You now have access/refresh tokens nice and safe on your server. But what does your web browser have? What goes out on any subsequent API calls it makes to make use of those tokens?
    – Andy N
    Commented Apr 24, 2019 at 8:39
  • The point of the authorization code is not for your web browser -- it is for the web app for make a call to a protected resource. If what you wanted was to access a protected resource via your browser, you'd request for the tokens directly and use them. The authorization code is for the use-case of delegating access to a 3rd-party, not for your own consumption. For that you just use tokens. Commented Apr 24, 2019 at 8:42
  • I'm not sure that's right. If true, what type of grant would you use from your browser? Implicit? Can you add a link to an explanation ?
    – Andy N
    Commented Apr 24, 2019 at 8:56
  • The RFC linked above has more details -- but maybe you mean Authorizatio Grant in a different context. What's the context you're referring to, i.e. what's the use-case you're looking to implement. Commented Apr 24, 2019 at 9:07
  • Standard single page app calling APIs. In the past I've used an implicit grant. I've been aware for some time that there are security implications using the implicit grant in this way. I'm starting a new project and I'd like to protect my APIs with the correct mechanism.
    – Andy N
    Commented Apr 24, 2019 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .