0

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?

Apyc
  • 307
  • 5
  • 12

2 Answers2

3

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.

Gary
  • 909
  • 9
  • 26
  • Thanks Gary. I have spent many days thinking about your option. Using the authorization header has seemed a very accepted standard. Both ways are vulnerable with XSS, but saving the id_token as a cookie also makes it vulnerable to XSRF / CSRF. That's the reason, but to be honest I still think about it because I don't like having to make all the queries by editing the header and adding the authorization. – Apyc Jul 22 '20 at 16:09
  • How is saving the encrypted token in a secure, httponly cookie vulnerable to xss? – Gary Jul 22 '20 at 19:42
  • As for csrf, the double submit cookie pattern should protect you here. I also add, for any administrative functionality, a database check just in case an admin account was compromised. By adding an isAdmin boolean to the access-token, if it's false, the endpoint immediately fails, but if it's true, I double-check the database for continued access. This way, a simple change to my admin user object is immediately effective vs. waiting for an access-token expiry. I only have 2 admin accounts so while this pattern of database checks goes against the jwt standard, it works for my peace of mind. – Gary Jul 22 '20 at 19:44
  • I too have spent weeks on this problem. I honestly wish I had just started w/simple opaque sessions. This rabbit hole is killing me. It's only when you code this yourself do you see the challenges as it appears so deceptively easy at first glance. – Gary Jul 22 '20 at 19:49
  • I wanted to add one more note - it has helped me to consider the alternatives. A session id. is what I prefer due to simplicity, but I only realized this after coding JWTs into my webapp. The only advantage I see that JWTs have over session ids. is the scalability of the architecture - as you don't need to access a database on every request. But now that my middleware is getting so advanced w/all these checks, I'm wondering if a simple database check isn't more efficient as well! – Gary Jul 22 '20 at 19:54
  • Ok Gary, thanks for sharing your experience, it helps me a lot, I have been lucky with you. With your information I think it is better to always use cookies. I use Symfony and it brings a tool for CSRF but it is not a double send, it is a token that is generated from the same word (per screen or form) not random, I am going to read more to decide. I do not understand why use XOR with cookies, if they are only http nobody can read them, the server will decrypt it comes the request of a good or bad user. I use JWT for scalability, but you're right, everyone says it's simple but it's a lie. – Apyc Jul 23 '20 at 09:43
  • It's not entirely clear what is meant here with 'I double xor them'? Can I assume that that means it's encrypted? I wonder since at first I read this advice as: "just store your refresh/access token in signed, secure http only cookie". That does seem like a bad idea if it's not encrypted. Since I do believe you don't want to give your user access to a refresh token. – Brecht De Rooms Feb 26 '23 at 20:03
  • Yes, the cookies are encrypted using a simple symmetric key to add some complexity for would-be attackers. – Gary Mar 10 '23 at 03:08
0

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 ..

Gary Archer
  • 22,534
  • 2
  • 12
  • 24