0
votes

I've been reading about it for a few days and I have two questions

1) If I store the access token in localstorage and the refresh token in an HttpOnly cookie, do I have to worry about XSRF? If the attacker cheats to make a request, the response is received by the good user. It is not bad that it requests a new acces token and a refresh token, the attacker cannot steal the content of the response. This is true ?

If the attack is XSS it can make the same attacks as if it also stored the access token as an HttpOnly cookie ... which is bad. But if you stored the refresh token in localstorage it would be very bad and you could update the access token.

With this approach I should not worry about XSRF, but if I store the 2 tokens in HttpOnly cookie I have to worry about XSRF (about the token to avoid XSRF) and XSS. And if they make a successful attack, they can only do evil the lifetime of the access token.

2) If my authorization server is a micro service and I access through an internal IP (10.x.x.x) I have to continue worrying about XSS but not XSRF, is this true?

2

2 Answers

2
votes

Have you considered saving both the refresh-token and the access-token (or id-token) to secure, httponly cookies? I do this and it works great. I also sign my cookies, and double xor them.

In your middleware function, you can check the validity of your access-token. If the access-token is valid, permit the access of the resource.

If the access-token has expired, check the refresh-token for validity (as it may be expired). If it's still valid, issue a new access-token via a cookie and permit the user access to the resource.

If the refresh-token is also expired, the user has to re-login.

0
votes

I think this area is often misunderstood, and generally I recommend:

  • Being very careful about risks, first and foremost
  • Once done, store access tokens in browser memory
  • Refresh tokens in cookies give you better overall options

A couple of relevant blog posts of mine:

Interested in feedback also ..