Where to store the refresh token on the Client?

61
votes

My SPA application uses the following architecture (source):

enter image description here

This assumes that my client application knows about the refresh token, because I need it to request a new access token if no user credentials (e.g. email/password) are present.

My question: Where do I store the refresh token in my client-side application? There are lots of questions/answers about this topic on SO, but regarding the refresh token the answer are not clear.

Access token and refresh token shouldn't be stored in the local/session storage, because they are not a place for any sensitive data. Hence I would store the access token in a httpOnly cookie (even though there is CSRF) and I need it for most of my requests to the Resource Server anyway.

But what about the refresh token? I cannot store it in a cookie, because (1) it would be send with every request to my Resource Server as well which makes it vulnerable to CSRF too and (2) it would send expose both access/refresh token with an identical attack vector.

There are three solutions I could think of:

1) Storing the refresh token in an in-memory JavaScript variable, which has two drawbacks:

  • a) It's vulnerable to XSS (but may be not as obvious as local/session storage
  • b) It looses the "session" if a user closes the browser tab

Especially the latter drawback makes will turn out as a bad UX.

2) Storing the access token in session storage and sending it via a Bearer access_token authorization header to my resource server. Then I can use httpOnly cookies for the refresh token. This has one drawback that I can think of:

  • a) The refresh token is exposed to CSRF with every request made to the Resource Server.

3) Keep both tokens in httpOnly cookies which has the mentioned drawback that both tokens are exposed to the same attack vector.

Maybe there is another way or more than my mentioned drawbacks (please let me know), but in the end everything boils down to where do I keep my refresh token on the client-side? Is it httpOnly cookie or an in-memory JS variable? If it is the former, where do I put my access token then?

Would be super happy to get any clues about how to do this the best way from people who are familiar with the topic.

6
authenticationcookiesoauthoauth-2.0token
Provide more information. Is this a SPA or server-based application? – jwilleke
In this case, it is an SPA. – Robin Wieruch
Would love to know what's the solution you've implemented? I'm currently using option 2, without worrying about CSRF. The refresh token is used and invalidated on every SSR. But this causes access tokens out of sync when the SPA is opened in more than one tab. – Yaobin Then

6 Answers

40
votes

You can store encrypted tokens securely in HttpOnly cookies.

https://medium.com/@sadnub/simple-and-secure-api-authentication-for-spas-e46bcea592ad

If you worry about long-living Refresh Token. You can skip storing it and not use it at all. Just keep Access Token in memory and do silent sign-in when Access Token expires.

Don't use Implicit flow because it's obsolete.

The most secure way of authentication for SPA is Authorization Code with PKCE.

In general, it's better to use existing libraries based on oidc-client than building something on your own.

31
votes

You can store both tokens, access and refresh, as cookie. But refresh token must have special path (e.g. /refresh). So refresh token will be sent only for request to /refresh url, not for every request like access token.

2
votes

Storing the access token in session storage and sending it via a Bearer access_token authorization header to my resource server. Then I can use httpOnly cookies for the refresh token. This has one drawback that I can think of: a) The refresh token is exposed to CSRF with every request made to the Resource Server.

You can set up the CORS policy correctly so that the requests to /refresh_token are accepted only from authorized servers.

If the client and server are served from the same machine, you can set the flag sameSite as true in the Cookie and include an anti-CSRF token.

1
votes

OAuth defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types.

__ RFC 6749 - The OAuth 2.0 Authorization Framework

The Authorization Code process is inherently designed to be used with a secure client, eg. a server, that is guarded enough to hold the Client Secret within. If your client is secure enough to hold that secret, just put the Refresh Token in the same secure storage as your Client Secret.

This is not the case with applications that are hosted in User-Agent (UA). For those, the specification suggests using Implicit grant type which presents the Access Token after the Redirection URI in a fragment after # sign. Given that you are receiving the token in the User-Agent directly, it is inherently an insecure method and there is nothing you can do about it except following that User-Agent's security rules.

You may restrict the usage of your application to specific User-Agents but that can easily be tampered with. You may store your tokens in a cookie, but that also can be accessed if the UA does not respect common security norms. You can store your tokens in local storage if it is implemented and provided by the UA, yet again if it respects the norms.

The key to these implicit indirect authorizations is the trust in UA; otherwise, the safest grant type is authorization code because it requires a safely and securely stored secret on a controlled environment (application's server).

If you have no choice but using the implicit call, just go with your guts and trust the user uses a safe UA that follows security protocols; any way you are not responsible for user's poor choice of UA.

0
votes

You are not using the best authentication architecture. The SPA is a public client and it is unable to securely store information such as a client secret or refresh token. You should switch to Implicit Flow, where refresh tokens are not used. But Silent Authentication (silent renewal) is available instead.

I recommend to use OIDC certified library, where is all already sorted for SPA apps. My favorite one: https://github.com/damienbod/angular-auth-oidc-client

0
votes

If your Auth provider implements refresh token rotation, you can store them in local storage.

But this means that your Auth provider should return a new refresh token every time that the client refreshes a JWT. And it should also have a way of invalidating descendant refresh tokens if one refresh token is attempted to be used a second time.

https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation