JSON Web Tokens vs. Sessions • Hacker News Board

Re: JSON Web Tokens vs. Sessions

#51

Post by atombender » Sat, Jun 18, 2016, 7:54 PM UTC

DenisM wrote: post #46

IIRC tptacek has been beating this drum for a while, but it seems that he got tired of it, so I should pick the drum sticks in his stead: Use less crypto. The less crypto is being used, the fewer mistakes are being made. When it comes to sessions, generated a secure random 256 bit token and use that as a session id. Store it in a database or in-memory store. Sticky sessions + local session token storage will fix your…

This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it.

For example, say client A calls service B, using a token signed by service C. Previously, we were using randomly generated session keys, which meant B had to ask C every time. But with JWTs, B can directly verify that the token is genuine without asking C, because it has C's public key.

We still check with C now and then, but that's because the token auto-expires. We use a long-lived master token stored in a cookie to generate new short-lived ones.

Re: JSON Web Tokens vs. Sessions

#52

Post by lobster_johnson » Sat, Jun 18, 2016, 7:59 PM UTC

mkagenius wrote: post #2

A security note regarding JWTs - https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i...

That one is from March 2015, and are about some specific libraries that had vulnerabilities at that time.

Re: JSON Web Tokens vs. Sessions

#53

Post by skybrian » Sat, Jun 18, 2016, 7:59 PM UTC

I didn't understand this part:

"if your application maintained a list of key/algorithm pairs, and each of the pairs had a name (id), you could add that key id to the header and then during verification of the JWT you would have more confidence in picking the algorithm"

This implies there's a security benefit, but I don't understand how it's better than checking the alg parameter against a whitelist. Perhaps if you're using non-standard names for algorithms, that guards against mistakes?

Re: JSON Web Tokens vs. Sessions

#54

Post by mschuster91 » Sat, Jun 18, 2016, 8:01 PM UTC

wtbob wrote: post #33

ninkendo wrote: post #19

Earlier quoted context omitted.

The JWT has to fit inside HTTP headers, which means it's not unlimited in size. The default header size limit varies by web server, but once you get above 8k it becomes a game of "which reverse proxy is choking on these headers this time?". It's compounded by the fact that a lot of web servers (ie. nginx) have a global header size that limits all of your headers together, not just any one header, which means your JWT…

> There's standard ways to include the JWT in the request body, like form encoding, but that doesn't work for GET requests, so in practice everyone uses the Authorization header. You can include a JWT as an access_token URL parameter, which works in a GET: https://foo.invalid/bar?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RM…

> You can include a JWT as an access_token URL parameter, which works in a GET:

Only works with IE > 11, and even IE 11 breaks down sometimes. Also, search engines choke on large URLs, see http://stackoverflow.com/a/417184/1933738

Re: JSON Web Tokens vs. Sessions

#55

Post by davb » Sat, Jun 18, 2016, 8:05 PM UTC

XHR? Sessions.

REST? Bearer tokens or OAuth.

Third party trust? JWT.

Re: JSON Web Tokens vs. Sessions

#56

Post by blazespin » Sat, Jun 18, 2016, 8:06 PM UTC

jwt are the capability model. They are not forgeable and they expire. You can revoke them by telling the database to ignore them by the token id. If you have a services based model you can pass them along and they can verify your capability without going to the db.

Re: JSON Web Tokens vs. Sessions

#57

Post by Alex3917 » Sat, Jun 18, 2016, 8:06 PM UTC

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…

> storing the "real" expiration in cache so that it can be extended (or revoked) as needed.

You can also have a password_last_changed field on your user model, where any token issued before this date is considered invalid. That was if a user's account somehow gets compromised, all they need to do is change their password and then all of their existing sessions are expired automatically.

I can't think of any good reason for storing the expiration dates of each individual token, although maybe there is a use case somewhere.

Re: JSON Web Tokens vs. Sessions

#58

Post by blazespin » Sat, Jun 18, 2016, 8:07 PM UTC

DenisM wrote: post #46

IIRC tptacek has been beating this drum for a while, but it seems that he got tired of it, so I should pick the drum sticks in his stead: Use less crypto. The less crypto is being used, the fewer mistakes are being made. When it comes to sessions, generated a secure random 256 bit token and use that as a session id. Store it in a database or in-memory store. Sticky sessions + local session token storage will fix your…

You think mistakes can't be made with session ids? Anyways, there are well trusted libraries out there for JWT.

Re: JSON Web Tokens vs. Sessions

#59

Post by blazespin » Sat, Jun 18, 2016, 8:10 PM UTC

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…

you can do a combination of session and jwt. your firewall manages the session, and the jwt can be used internally and effective decouples your architecture and the firewall (except you will need to send a logout message to the firewall if the user choses to logout)

the jwt is useful as a capability model if you've broken your internal arch into stateless microservices.

Re: JSON Web Tokens vs. Sessions

#60

Post by blazespin » Sat, Jun 18, 2016, 8:13 PM UTC

nawitus wrote: post #50

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 people using JWT as a substitute for stateful sessions, how do you handle renewal (or revocation)? You can do the inverse, e.g. instead of storing 'active sessions', you just store 'revoked sessions'.

yeah, but the problem with that is you're just using the token as a session id.