OpenID Connect: Is storing access token in browser secure?

Question

I'm currently in the phase of integrating my web-site to OpenID Connect provided by KeyCloak. The web-site is not a single page application. However, different parts of the application are delivered by different web services.

In each site delivered by these different web services, the user can call a standard REST API. This REST API can only be accessed with an access token received from KeyCloak. Thus, the user needs to log-in on the web-site using authorization code flow of OpenId Connect offered by KeyCloak and use the access token given by the token endpoint. This request with the access token can be either sent by browser or by one of the back-end services delivering the current web-site. Thus, we can either do a a client-side integration or server-side integration with the REST API.

Unfortunately, the server-side integration is not that feasible due to the complex structure of back-end systems. I cannot even integrate most of web services with KeyCloak. Thus, I could store the access token in the browser in local storage and access to the REST API directly from browser. However, I'm still unsure if storing the access token in browser will bring a security vulnerability.

I could not see any official statement regarding this in the standards, so far. I have seen applications both storing it in the back-end and storing in the browser and I still can't tell the exact security benefit of using a session over an access token when we store it in the back-end. I do not intend to save refresh token in the browser and use only authorization code flow with the help of a back-end service.

My questions:

• Is it a security vulnerability to store the access token in browser? E.g., in local storage, in a cookie with HttpOnly, or both of them?
• Is there a way to mitigate the security threat and still store it in browser?
• Is there a best practice or guideline for storing the access tokens of OpenID Connect that you could refer to?
• What is the difference from the security perspective between storing the access token and session, if we can use the session to access the API over an intermediary service?

Thank you for your assistance in advance!

Answer 1

Is it a security vulnerability to store the access token in browser? E.g., in local storage, in a cookie with HttpOnly, or both of them?

In local storage : yes, it can be easily accessed from another domain.

In a cookie with HttpOnly, the browser (if it respects the standard) will only "display" it by attaching it to request send to your domain. Be sure to be protected against CSRF.

Is there a way to mitigate the security threat and still store it in browser?

If you store it in your memory tab, only your code can access it, but someone could inject some malicious code into yours. So you have to be protected against JavaScript injection (and you can't be fully fully sure of that !).

You can reduce the lifetime of the token.

Is there a best practice or guideline for storing the access tokens of OpenID Connect that you could refer to?

Some security cloud services give good guidelines to implement their services (based on open id connect / oauth2). Have a look at AuthO or Okta for example.

The common way of using it is to add the access_token in Authorization header with Bearer prefix. Store it in memory of your tab.

You can also store it in your backend and give a session to the browser, but this only works with a front gateway and/or with shared session (over Redis for example)

What is the difference from the security perspective between storing the access token and session, if we can use the session to access the API over an intermediary service?

It depends if you talk about oauth2 or open id connect. Please have a look here. A session is stored in the memory of a server, so it can be revoked easily and store data server side. An access token, once emitted, is always true until it's expiration date.

This answer is based on my current knowledge at this time, it may evolve later ! Hope this help.