4 ms·
You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.) (Now, if you
by deathanatos 8y ago
You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.)
(Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)
- yen223 8y agoThe more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.
- deathanatos 8y agoSession tokens (an unguessable identifier that identifies server-side stored session data), while they don't need to be encrypted or signed, the identifier should usually be cryptographically random, however, so you can still get into trouble there. JWTs don't have to be encrypted. (And IME, typically aren't.) They need to be signed, but the algorithms that do this are common, well-understood algorithms. Some of them are likely being used by TLS to protect your session anyways. If they're not foolproof, you have bigger issues than JWT. If you are referring to the implementation, then sure, but the same concerns exist about your implementation of TLS, and the same advice applies: use a well-known, hopefully well tested library.