Why are Refresh Tokens considered insecure for an

Question

I was reading the documentation on the Auth0 site regarding Refresh Tokens and SPA, and they state that SPA's should not use Refresh Tokens as they cannot be securely stored in a browser, and instead use Silent Authentication instead to retrieve new Access Tokens.

A Single Page Application (normally implementing Implicit Grant) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.

I'm confused. From my understanding, the only way to retrieve a new access token would be to submit a new request to the Auth server, along with some form of an Auth0 session cookie to authenticate the user that is logged in. Upon receiving the session cookie the Auth0 server would then be able to issue a new Access Token.

But how is that any different than having a Refresh Token in the browser or in the local storage? What makes the Session Cookie any more secure than a Refresh Token? Why is using a Refresh Token in an SPA a bad thing?

Answer 1

Good question - So there is no really secure way to store any tokens on a Browser (or any other confidential info) - see links such as this. Hence Single Page Apps (SPA) should not store a refresh token - a refresh token is particularly problematic, because it is long lived (long expiration or no expiration), and if stolen then an attacker can continue to refresh access tokens after each individually expires.

It would be better to just retrieve your access token when you need it (for instance to call an API) and either store only in memory (still vulnerable to XSS / CSRF) but better - or use and forget. Then make another checkSession call next time you need an access token.

To your question - the checkSession request does not require sending a Token. It is literally as the name suggests - a "check session" against the Authorization Server to see if a Session exists. If it does, then the Authorization Server response will include a fresh access token. See here for an example usage with SPA

Please feel free to leave me comments beneath this answer if anything requires more clarification etc.

Answer 2

The refresh tokens are not used in SPAs, because in order to use it - and to get a new access token from the /token, the SPA needs to have a client secret, which cannot be stored securely in a browser. But since the OAuth 2.0 for Native Apps RFC recommends not requiring a client secret for the /token endpoint (for public clients), the refresh tokens could be used even in SPAs.

To get a refresh token, you need to use the Auth code grant, which passes the code in a redirect URL, which goes to the server hosting the SPA (which can be an extra point of attack). The Implicit grant delivers tokens just to a browser (hash part of the redirect URL doesn't get to the server).

The difference between using a refresh token and an SSO session cookie - the cookie is probably more secure, since it can be marked as HttpOnly, making it inaccessible for attacks using JavaScript code.