Where is the OAuth access token stored in the browser in case of Authorization Code Grant flow

Question

I entered my credentials and logged into a web application protected by OAuth Authorization Code flow. Then I performed below steps:

1. Open browser developer tools (F12) and start capturing network traffic
2. Try to get data from an API. This request will require access token to be sent. But I am able to view the access token on the network tab for that particular request in the request headers as seen in screenshot below:

My understanding was as below:

1. The access token would be stored on the web server where my web application is running. That will never be stored in the browser.
2. Since I am able to see it in the network tab, where exactly is the access token stored in the browser? We use Azure AD as the IDP and Owin packages to integrate OAuth auth code flow.
3. The API request is over HTTPS and I am able to view the full request details in network tab. Is this expected?

Solution

There are only so many places where you can persistently store data in the browser.

As of this writing:

• Cookies
• Session Storage
• Local Storage
• IndexedDB
• Web SQL

If you are using libraries to implement the OAuth2 flow any of these could be used. You can find and inspect these storage systems under the "application" developer tools tab in Chrome, or similar spots in other browsers. What you can see/inspect depends on the domain you are currently on in the active tab.

1. If your client is server based, and thus confidential, you should store your token in a Secure HttpOnly cookie. Then proxy requests to the backend through your own server, including the bearer token from the cookie. This would be the best spot.

2. If your client is a single page application, you should consider storing it "in memory" and just reauthorize when reloading the page.

3. If that is not an option then Session Storage is your most secure option. This is most often used if OAuth2 is performed by your frontend.

In any case, if the OAuth2 flow is performed by frontend components only, it is to be expected that the token resides somewhere in the mentioned storage systems, and that it is included in the requests as visible in the network tab of your developer tools.

Comments

[juunas]

I don't think we can say where your app is storing the token. Of course you can view the request details in your browser. Your browser sees the decrypted data. It wouldn't be able to display anything otherwise :)

[variable]

Once the app server receives the ID token (which contains claims), then does it send that token to the browser? So that subsequent api calls can pass that id token to allow app server to know who has invoked the endpoint.

[sg3s]

@variable That is not what this question is abou. You could learn more about general OAuth2/OIDC by googling and reading about it online - it might already answer your question. If that doesn't help you, post a new question please.

[Igor]

No, it is incorrect answer. In case of Authorization Code Flow you are not allowed to store tokens somewhere in browser, doesn't matter whether it cookies, session storage or something else. You must generate session cookies and associate them with tokens, store tokens on backend side, session cookies provide to browser. What you described is Implicit Flow

[sg3s]

@Igor It is not incorrect. The spec doesn't prescribe where you must or mustn't store your access token. The recommendation however is to handle it as I outlined in the answer. I did not describe implicit flow, I did not describe any specific flow in the OAuth 2 spec, in fact it is sincerely recommended to not use implicit flow, as it is deprecated in favor of auth code flow + pkce. How to retrieve tokens and how to store them are two different things. This was a question on where a token is stored.

[Igor]

@sg3s your recommendation is wrong. First of all, the question was regarding Authorization Code Flow, but you addressed Implicit or Hybrid Flows. Second, documentation clearly describes who and how communicates openid.net/specs/openid-connect-core-1_0.html#Authentication "server-to-server", End-User never has any tokens, Relying Party does. End-User only forwards auth code to RP. Another answer stackoverflow.com/a/44655679/278089. In case of Implicit or Hybrid Flow, token can be in End-User possession.

[sg3s]

@Igor I don't know what to tell you. I think your understanding of the spec is incomplete. The other answers mentions how the browser can be the client too, and even mentions where typically the cookie is stored, which is what this answer was about, nothing else. Maybe something got lost in translation, but there is no wrong advice here.