I'm trying to figure out how to use JWTs that are transmitted in cookies for an SPA It needs to be in cookies because we want non-ajax requests to also send the jwt, and it should "just work" for all subdomains. I have the cookie with the token being generated and updated fine on the server side. What I'm trying to figure out is how the client side should get at the info (is_logged_in and username of logged in user essentially) and keep that info in sync with the server side cookie life cycle, as I want expiration after say 1 hour of no requests, and it should show up on the browser when that happens. My problem is that the user info I want is in a cookie that is http_only to prevent XSS. I've thought of a couple of options, and would like opinions on what's a reasonable security compromise:

1) send the identical jwt token in two cookies, one used for actual server side auth & auth, which is flagged http_only and secure, and a second one which is identical but is not http_only so the client can decode it to get current user info and expiry time.

2) send the user info in a second cookie that is not http_only and is plain view, but has only username of logged in user.

3) try to have the client keep track of login info on its own, this seems problematic so far and easy to futz up but has no insecure cookies flying around.

I'm thinking I could well be missing some security aspect of the above options, hence asking here. thanks!

2 Answers 2


This sounds fine, and seems like a good solution to protect the session cookie against XSS attacks by duplicating the value of username into a non-http only cookie.

All your authorisation checks should be being made server-side anyway. So if your client wants to do something server-side, it sends the request and then the server makes the authorisation checks itself, not taking into account the non-http only cookie at all - it just uses the session cookie protected by http only.

If the non-http only is used for UI purposes only, it can't harm the session because the server will vet all requests using the session cookie.

  • Thanks, that is what I'm thinking and you expressed it better than I did. I'm going to wait to see any other answers before marking this as correct in case there are dissenting opinions. Appreciate the feedback. Aug 10, 2015 at 15:35
  • No problem. Let me know if you need any more info. Aug 14, 2015 at 18:10

I had to read your question a couple of times to understand what you were describing in option one - if your session cookie contains a predictable, clear text value (in your example the authenticated username and the redundant fact that they are authenticated) then your security is fundamentally broken. Session is should be random or encrypted with time varying initialisation values / salts.

In your second option, assuming the session cookie is secure, what is the consequence of the second, insecure cookie being compromised? Not very much. Although it's worth noting that most of the means by which the cookie could be compromised amount to a man in the browser type attack (including xss) at which point the attacker will be able to exploit the session cookie to create requests originating from the victims browser.

  • Ok, but in both options, I'm talking about the cookie that the server pays attention to for auth being an http_only, secure cookie, containing a jwt token. Without the jwt secret key, that cookie can't be tampered, only stolen. The second cookie (in either case) is something the server is not going to pay any attention to, it's just going to be used to send the username (for display on screen) and the logged in flag (for page behaviour) to the Angular app. It won't allow the angular app to download content. Stealing/altering the second cookie wouldn't get you any access. Does that make sense? Aug 7, 2015 at 3:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .