1

I'm wondering what are the nowadays risks of storing a JWT that does not expire in an HttpOnly, SameSite=Strict, and Secure cookie.

I understand localStorage is vulnerable to XSS, and that normal cookies are vulnerable to CSRF, so that's why it's recommended to use temporary JWTs with refresh tokens.

My idea is that the JWT would be issued at login time and would only include the user ID. It would be sent in an HttpOnly, SameSite=Strict, and Secure cookie. On logout, the cookie storing it could be overridden by the backend. Additionally, to avoid keeping cookies around when a user does not log out, they could have a MaxAge attribute.

Is it plausible?

Thanks in advance.

3

The most fundamental rule of web application security is you can not trust the client.

The expiry date is the single most important security feature of a JWT, because it's the only way you can tell the difference between an old stolen token and a newly created one.

A JWT with no expiry is like a skeleton key: if anyone gets hold of it, they can carry on logging in as that user, forever. Sure, if the browser obeys all your restrictions, and deletes it as soon as you tell it to, the skeleton key won't leak anywhere. But why create the skeleton key in the first place, when it's trivial to avoid?

You mention adding a max-age to the cookie, so you already have an idea of what a reasonable session lifetime would be; use that as the expiry date in your JWT.

1
  • Makes sense, thanks!
    – lewislbr
    Mar 25 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.