Skip to main content
Information Security

Return to Question

Notice removed Authoritative reference needed by Andy N
Bounty Ended with desr's answer chosen by Andy N
added 642 characters in body
Source Link
Andy N
Andy N
  • 510
  • 1
  • 3
  • 13

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?

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!

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?
Notice added Authoritative reference needed by Andy N
Bounty Started worth 50 reputation by Andy N
Source Link
Andy N
Andy N
  • 510
  • 1
  • 3
  • 13

Does an authorization code grant rely on sessions?

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!