Understanding the securing of access tokens and refresh tokens

Question

Based on this article and this question, refresh tokens are to be long lived and access tokens are to be short lived. I would store my refresh token for more or equal to 60 days and my access token for 20 minutes or more/less but never more than an hour.

My main pain point in understanding the use of these tokens is the storage method for both tokens. I understand that I should store the refresh token as httpOnly making it inaccessible via script (XSS attacks) and store the access token locally, either localStorage or sessionStorage for use in API calls as a key. Is it the correct way to do so? Should I further encrypt the refresh token as recommended in the article? Any insight would be much appreciated, thanks for reading.

Answer 1

First of all you need to understand, that there is absolutely nothing you can do to prevent the extraction of the tokens once the attacker gets his hands on the victims user agent (browser). No encryption is going to help. You would need to hold the encryption key somewhere on the client which makes the whole idea of encryption IMHO pointless. Sometimes people are forced to encrypt stuff like this because they want their little sisters to have no access or because big corporations have dumb policies you have to comply with.

I see you are willing to hold the refresh token in a cookie. That's ok, just make sure you put the right configuration in place. This presentation should help.

One last word of advice. Session security is not only about session security. You need to do TLS, data sanitization and access control too. If you forget TLS then no token storage strategy will help.

Answer 2

For best security + overall architecture:

• Access tokens should be stored only in browser memory - to be secure enough
• Refresh tokens work better in cookies - to enable things like browsing from app 1 to app 2 without redirects

Understanding the reasons why is quite deep though, as in my blog posts below:

• Web Architecture Goals
• Browser Token Security
• Token Refresh for Web UIs

You may have different goals to mine though. Happy to answer follow up questions if it helps ..

Answer 3

To directly answer your question: No, there is no reason to encrypt a refresh token.

The only reason to encrypt a cookie is if it contains information that needs to be protected, like an account number, password, etc. A refresh token contains no meaningful data - it is just a long random number that points to an entry in the server's datastore.