My SPA application uses the following architecture (source):
https://i.stack.imgur.com/BPJjA.png
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.
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.
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.
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.
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
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.
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
Success story sharing
access_token
in sessionStorage, so you can do the same. However, it increases visibility to any malicious scripts. 3) I believe, there is no common and secure solution to solve the original problem. If you have something on client, then any browser extension or injected script can access that data.do silent sign-in when Access Token expires
?401
. Usually, there is a 'refresh token' which is kept on the client. And after having 401 as response, UI should refresh the 'access token' using the 'refresh token'. If there is no 'refresh token', then UI can simply re-authenticate user and obtain fresh 'access token'.