Most blog posts that I ever read suggest to use httpOnly cookies in order to securely store jwt token on client side (javascript applications). I have a few questions regarding this (which I could not find on those blog posts).
- If jwt token is stored in httpOnly cookie, the javascript application cannot access the token and cannot know the auth state of current user. How do we handle this ?
- Does "using httpOnly cookie" comply with REST's Statelessness on API side ?
- Is "using localStorage for jwt token" just fine ? We just need to beware of XSS ?
CodePudding user response：
The suggestion of using httpOnly is to avoid malicious code (e.g. XSS, script injection) to be able to read the JWT. That is under the assumption that auth is done solely in the backend side and if the Javascript code needs to extract some info from JWT, httpOnly doesn't work.
I don't think it has to do anything with the REST's statelessness.
Using localStorage has this risk but if it is required, yes you need to be careful.
CodePudding user response：
If jwt token is stored in httpOnly cookie, the javascript application cannot access the token and cannot know the auth state of current user. How do we handle this ?
The token may be hidden from the client, but that doesn't mean that the client can't have any information. When the client makes a successful request to the server, and the server authenticates the client, the response can include the JWT in an HttpOnly cookie, and the client, upon seeing that it was successful, set a flag in, say, local storage, indicating that a cookie exists (even though it can't be accessed by the JS), or indicating the date of the cookie's expiration.
This value in storage could then be used by the client on future pageloads to see if making a request to the server will probably succeed (that is, that an HttpOnly cookie exists, and that it contains a valid JWT). If the value exists, the client can make a request, the server can validate the cookie, and send back information to the client, without the client ever having direct JavaScript access to the JWT.
That said, this approach is slightly cumbersome, and only really suitable for when there may be other not-necessarily-trustworthy code running on the page. This is the approach I use when one of my apps runs on a page on an external domain I don't control, with other scripts I don't know enough about - using an HttpOnly cookie means that my server can safely store client information there without having to worry as much about what other scripts on the page might be doing.
If the page the app is running on is your own, you could well choose to store the JWT in a plain (non-HttpOnly cookie) or in local storage, and access it via JavaScript.
Is "using localStorage for jwt token" just fine ? We just need to beware of XSS ?
If it's on your own page, yes, for the most part. If the JWT is accessible with JavaScript, malicious JavaScript can scrape it - that's the only worry.