3

A common scenario for user authentication follows these steps:

  1. User registers and logs in using its credentials (username/password)
  2. The server verifies the user's credentials and, if valid, returns an access token and a refresh token
  3. The access token is sent on further requests and, if it is valid, the server responds with the requested resource
  4. When the access token is no longer valid, the server requests the client to provide a refresh token in order to issue a new access token
  5. The server receives the refresh token and two things may happen:
    • if the refresh token is valid, a new access token is issued to the client
    • if not, the server requests the user to authenticate

For the client to be able to send the access token in every request, the token should be stored either on browser storage (local/session storage) or cookies, which makes it vulnerable to XSS (Cross-Site Scripting) attacks. This problem may be mitigated if we set a short lifetime to the access token.

My question, however, is regarding to the refresh token. This token should have a long lifetime and since we use it to get new access tokens, it would be a problem if an attacker would intercept it. So storing this token on the client side might not be a good idea, right?

But, what are the alternatives?

Can we store it in a cookie set with the "httpOnly" flag? But wouldn't this make it vulnerable to CSRF (Cross-Site Request Forgery) attacks?

Is it safe to encrypt the token and still save it on browser storage?

Thank you in advance. Best regards!

1 Answers1

2

which makes it vulnerable to XSS (Cross-Site Scripting) attacks.

To clarify, the cookie is only vulnerable to a XSS attack should there be a vulnerability on your site that makes this possible.

Can we store it in a cookie set with the "httpOnly" flag? But wouldn't this make it vulnerable to CSRF (Cross-Site Request Forgery) attacks?

Although the httpOnly flag cannot be used in some forms of CSRF protection due to the need for it to be accessed client-side, flagging a cookie as httpOnly does not increase the risk to your system in any way - httpOnly is more restrictive.

Is it safe to encrypt the token and still save it on browser storage?

Not really because anyone or anything that can access browser storage can access the cookie value and present it. It doesn't matter what form it takes - encrypted or not - if it can be used directly without an external key. Don't worry about this too much - put trust in the browser to keep this secure, however ensure the rest of your site is as secure as possible.

You are right that the refresh token is viewed as more sensitive than the access token. You can store this in a cookie, however make sure that it is set to httpOnly and has the secure flag set too to ensure it is only transmitted over encrypted HTTPS connections.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • First of all, thank you for your response ;) Regarding your first point, what I was trying to say is that storing a token in a cookie would make it vulnerable to XSS, since this cookie would have to be accessed by client-side (to get the token and use it in the authorization header) and thus the "httpOnly" flag (which allows protection against XSS) would not be set. Is this not right? –  Dec 02 '15 at 15:57
  • Regarding your second point, I'm not sure I'm understanding it. Can you clarify a bit, please? Thank you again ;) –  Dec 02 '15 at 15:58
  • Yes, the first comment is correct. I would just rephrase it and say that the cookie "could be hijacked should my website be vulnerable to XSS". Please see this [OWASP article for a good explanation of CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)). What I was saying that having an httpOnly cookie does not make you vulnerable to CSRF. – SilverlightFox Dec 02 '15 at 16:11
  • I see, I understood now ;) Thank you! –  Dec 02 '15 at 16:14