I have read a lot of articles about where to store JWTs and there seems to be a lot of people backing both sides of the local storage vs cookies argument.
Microsoft says this about token based authentication:
To send the token on subsequent requests, store the token in the browser's local storage. Don't be concerned about CSRF vulnerability if the token is stored in the browser's local storage. CSRF is a concern when the token is stored in a cookie.
While post such as this strongly advocates the use of cookies:
The biggest security offenders I see today are those of us who store JWTs (session data) in local storage. Many people don't realize that JWTs are essentially the same thing as a username/password.
I would like to create an API that is accessible to both SPAs and mobile apps.
My understanding is that the SPA could/should use a cookie with:
new CookieOptions
{
HttpOnly = true,
SameSite = SameSiteMode.Strict,
Secure = true
}
While the mobile app would store the JWT on the device and add it to the Authorization header of each request as it has no concept of cookies.
In previous projects I have used jwt-decode in my SPAs to parse user information (such as roles) from the token. How would this work if I was using a HttpOnly cookie as I would not have access to the token?
In short, is it safe to store JWTs in local storage or should it always be a cookie. If a cookie is required how do I determine roles etc. for the user in the client side app?
XSS
. But as far as I know, if somebody is able to inject js script into your website, he is also able to do most of the parts that a real user can do. In that case, nothing is secure including cookie. Cookie & Session works sometimes. But the problem is what if we have multiple servers that need to share those Cookies & Sessions? I believe the comment by Jonathan Gros-Dubois is great. – itminus