Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens vs. Sessions

float-middle.com

Post reply on HN
Print view View original

21–30 of 173 posts

Re: JSON Web Tokens vs. Sessions

#21

Post by moyok »

StevePerkins wrote: post #14

For people using JWT as a substitute for stateful sessions, how do you handle renewal (or revocation)? With a traditional session, the token is set to expire after some period of inactivity (e.g. one hour). Subsequent requests push out the expiration... so that it's always one hour from the last activity , rather than one hour from initial authentication . With JWT, the expiration time is baked into the token and see…

For this, you can use refresh tokens and set the JWT expiration to a low interval - say 10 minutes. After every 10 minutes, the JWT expires,authentication fails, and the client uses the refresh token to get a new JWT. To revoke a client, revoke their refresh token. This way, though they won't be logged out immediately, they would be logged out in a max of 10 minutes when they need to refresh again, and find out that their refresh token is no longer valid. The point is that instead of every request touching your DB or cache, only one request does in every 10 minutes.

Re: JSON Web Tokens vs. Sessions

#22

Post by mkagenius »

Negative1 wrote: post #10
smaili wrote: post #4

Correct me if I'm wrong but the benefits sound very similar to a good old fashion cookie except that you're not limited by 4kb.

This is the common misconception. Think of a cookie as a storage 'bucket' on a user's device. It can store up to 4KB in bytes of, well, anything (a string). JWT is format. That's it. It is enciphered and has the ability to store JSON, but otherwise, it's just a format or scheme that allows you to organize how you store your session (or whatever) data. As an example, in my usage I actually store my JWT in a user cooki…

> but am comfortable exposing in case the token is cracked.

If the token is cracked, it is essentially the account compromise. You probably meant the base64 decode if the token is 'leaked'?

Re: JSON Web Tokens vs. Sessions

#23

Post by tszming »

People don't realize it is not a proper comparison as JWT is only the format/spec - you can still achieve stateless client session by encrypting an XML payload (e.g. user id) in the browser cookie. Storing data in client and verify by signature is not a new thing.

Re: JSON Web Tokens vs. Sessions

#24

Post by moyok »

The thing that scares me about using JWT is that all security completely relies on the one secret that is used to sign tokens - any person with access to that secret has got potentially unlimited access to the app. They can now impersonate any user and do basically anything.

Re: JSON Web Tokens vs. Sessions

#25

Post by ekryski »

Negative1 wrote: post #10
smaili wrote: post #4

Correct me if I'm wrong but the benefits sound very similar to a good old fashion cookie except that you're not limited by 4kb.

This is the common misconception. Think of a cookie as a storage 'bucket' on a user's device. It can store up to 4KB in bytes of, well, anything (a string). JWT is format. That's it. It is enciphered and has the ability to store JSON, but otherwise, it's just a format or scheme that allows you to organize how you store your session (or whatever) data. As an example, in my usage I actually store my JWT in a user cooki…

I agree that's how we treat them with Feathers. You may know this already but JWT's are intended to be decrypted on the client so you shouldn't be be saying "if" it is cracked, more "when". The signature is only good for ensuring that the content hasn't been manipulated. Not that you are, but for others, never store anything inside a JWT that is sensitive, and if it is make sure you encrypt it first before you put it in the JWT payload.

Re: JSON Web Tokens vs. Sessions

#26

Post by nneonneo »

bigonlogn wrote: post #15
nstart wrote: post #9

That last part where he talks about logging out being the responsibility of the client is rather key. Basically I can't invalidate the key from the server side. So if a user's account is compromised and they recover it on their mobile app for example, I can't sign the user out of everywhere else too. It's what has given me pause about jwt so far and has held me back from using it. I find the cookie is generally good…

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.

If the user reauthenticates and you unset the reauth flag, wouldn't their previous sessions (e.g. tokens held by an attacker) suddenly become valid again? How would you prevent such an attack?

Re: JSON Web Tokens vs. Sessions

#27

Post by tptacek »

darksaints wrote: post #20
StevePerkins wrote: post #14

For people using JWT as a substitute for stateful sessions, how do you handle renewal (or revocation)? With a traditional session, the token is set to expire after some period of inactivity (e.g. one hour). Subsequent requests push out the expiration... so that it's always one hour from the last activity , rather than one hour from initial authentication . With JWT, the expiration time is baked into the token and see…

With JWT, you have the option of stateful or stateless. Stateless gives you cheap federation (any server can authenticate a token issued by another server), but you lose the ability to handle revocation without some sort of statefulness introduced (a redis cache with revoked token ids for example). Stateful is basically a non-cookie based session. One possible alternative to enable auto-renewal is to issue a new toke…

"A Redis cache with revoked token IDs". Default-allow revocation. What's not to love about JWT?

Re: JSON Web Tokens vs. Sessions

#28

Post by inopinatus »

nneonneo wrote: post #26
bigonlogn wrote: post #15

Earlier quoted context omitted.

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.

If the user reauthenticates and you unset the reauth flag, wouldn't their previous sessions (e.g. tokens held by an attacker) suddenly become valid again? How would you prevent such an attack?

You wouldn't use a boolean flag. I suggest setting a validity timestamp for the user, and reject any token that was issued-at any earlier time.

(This isn't a perfect scheme since a compromised issuer could have been induced to send post-dated tokens. If your need for global logout was to invalidate tokens issued by a compromised issuer, you'll need to blacklist keys as well)

Re: JSON Web Tokens vs. Sessions

#29

Post by tszming »

bigonlogn wrote: post #15
nstart wrote: post #9

That last part where he talks about logging out being the responsibility of the client is rather key. Basically I can't invalidate the key from the server side. So if a user's account is compromised and they recover it on their mobile app for example, I can't sign the user out of everywhere else too. It's what has given me pause about jwt so far and has held me back from using it. I find the cookie is generally good…

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.

Effectively now you are using database as your session storage?

Re: JSON Web Tokens vs. Sessions

#30

Post by wtbob »

moyok wrote: post #24

The thing that scares me about using JWT is that all security completely relies on the one secret that is used to sign tokens - any person with access to that secret has got potentially unlimited access to the app. They can now impersonate any user and do basically anything.

Yes, it'd be better if JWTs were full-fledged certificates, where ultimate authority could be confined to some offline key, who delegates authority for strictly delimited period to online keys. Or ultimate authority could belong to k out of a collection of n keys: one would need to suborn k keys to suborn the authority as a whole.

RFCs 2692 & 2693 specify a really great, lightweight, way to do that. They resulting certificates needn't be a whole lot heavier than a JWT, and are much lighter-weight than and X.509 certificate. The RFCs also specify an intelligent, domain-neutral algorithm for performing calculations on tags (what JWT refers to as 'claims') and keys.

It's a pretty awesome solution, and there are a lot of good ideas in there. A streamlined version could, I think, end up being competitive with JWTs.

Post reply on HN