Why can't I store an oauth refresh token in the browser?

Question

I want to store an oauth refresh token in the browser. The reason I want to store it there is so that the app can refresh the access token and let the user continue their session uninterrupted. I also want to eliminate the need for any kind of cache on the server to store the tokens, thus making it stateful.

I'm told that storing the refresh token in the browser is wrong because it's insecure.

I think it's OK because:

• The tokens would be stored in httpOnly, secure session cookies so they shouldn't be vulnerable to XSS or man in the middle attacks and they will be discarded when the user closes their session.
• All communication to the server is done via HTTPS
• The refresh token can be invalidated if suspicious activity is detected
• Most importantly you can't use the refresh token unless you know the client secret which would be known only by the server.

Am I wrong to think it should be OK? Please explain why!

Lupercalia

Answer 1

Storing the tokens in an httpOnly, secure cookie is probably the best you can achieve security-wise. The problem sometimes is that an httpOnly cookie is not good enough due to other (non-security) reasons as Javascript obviously does not have access (that's the point). So people sometimes want to store tokens in other browser stores like localStorage, or slightly better, in JavaScript objects, both of which are significantly less secure than an httpOnly cookie (but still may be good enough for some applications).

Storing the token in an httpOnly and secure cookie makes it pretty much equivalent to a session id, and its security will also be the same in this respect (obviously other aspects may be different).

Lepanto

and the cookie is auto sent with subsequent requests? If yes, then, if someone is able to inject malicious js, and start making requests, he will be able to use the cookie. Although can't explicitly read it directly. – Vicenary

Yes with xss he would be able to use the cookie as long as there is an xss opportunity, but that requires user interaction, as opposed to having the token and sending it from another (the attacker's) client. – Lepanto

xss attack is mitigated when you mark your stored token in cookie as httponly. For f yes, then, if someone is able to inject malicious js, and start making requests, you can use a CSRF token to validate the request. It can be put in the JWT token itslef to validate the request on server side. – Embry

Answer 2

Actually you can store your token in the browser, you just need to know which store mechanisms fits better with your solution. For example in the local storage is the least safe of all, if you have the backend and your Single Page App at the same domain I would recommend you using the cookies.

Auth0 website has some recommendations about it:

We recommend using the Auth0 Single Page App SDK. The Auth0 SPA SDK handles token storage, session management, and other details for you.

For further details click here.

Resiniferous