JSON Web Tokens vs. Sessions • Hacker News Board

Re: JSON Web Tokens vs. Sessions

#41

Post by moyok » Sat, Jun 18, 2016, 7:06 PM UTC

zackmorris wrote: post #37

moyok wrote: post #21

Earlier quoted context omitted.

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…

I know this works, and I've used it, but I also find it to be the most aggravating thing about JWT and also OAuth. With OAuth, some sites allow you to refresh a token after it times out (so really the refresh token is the source of truth, defeating the purpose of the OAuth token), and others only allow you to refresh before it times out (forcing a login by the user if they are disconnected too long, or storing their…

I have personally experienced the security disadvantage you mentioned. I used my Google login to sign into an email client. I immediately realised that the app was going to store all of my email data in their private servers. I quickly went over to the Google dashboard and deauthorised the app, relieved that they would only have been able to get my first few mails in this time. But the app retained access to my emails, even receiving new emails for some time. Probably because of something similar to a refresh token being revoked, but the access token still being valid. I wanted to stop the app from accessing my e-mails, but could not.

However, despite this disadvantage some applications just cannot afford the load of every single request touching the DB or cache. JWT makes sense for that particular use case when you are willing to make this compromise. Instead of every single request touching the cache, maybe every 1000th request does now, because of the token expiration time.

Another use case is when you need a very simple, stateless way to authenticate users and don't require revocation. Some Oauth providers don't give you the option to revoke access tokens, for example.

Re: JSON Web Tokens vs. Sessions

#42

Post by vmarsy » Sat, Jun 18, 2016, 7:08 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…

Could this be an issue if you try passing the refresh token as well? Is there some limit for the length of a GET request parameters?

Re: JSON Web Tokens vs. Sessions

#43

Post by paulftw » Sat, Jun 18, 2016, 7: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…

Think how you would do that with session cookies - you either issue a fresh cookie or ask for login/password. Same with JWT - your client-server API wrapper can add a renewed token to a response when needed. There are many other reasons to have central API wrapper on the client (common error checking, serialisation, headers etc) so it doesn't cost much to stick an extra check for a new token

Re: JSON Web Tokens vs. Sessions

#44

Post by skylan_q » Sat, Jun 18, 2016, 7: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…

I found this: http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.p... here: http://security.stackexchange.com/questions/7398/secure-sess... And implemented it. It was quick, cheap, and easy enough for me to assign a new token with most (if not every) request that required authorization/authentication. The only bits of info kept in the cookie were insensitive bits of data, so if a single token got cracked it wouldn't be a huge deal.

Re: JSON Web Tokens vs. Sessions

#45

Post by palmdeezy » Sat, Jun 18, 2016, 7:12 PM UTC

This is the 3rd or 4th article in the last 3 weeks on JWT. Each has argued that JWT is either secure or totally useless. What is the deal?

Re: JSON Web Tokens vs. Sessions

#46

Post by DenisM » Sat, Jun 18, 2016, 7:23 PM UTC

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 network latency problems when you start scaling out.

Federation becomes moderately difficult. Perhaps you could store a copy of session id on each node, and when a session id is compromised, proactively reach to all nodes and ask them to purge the session. This allows immediate mitigation for a session id leak, and since it doesn't rely on timeouts there is no vulnerability window for data exfiltratiin upon a breach. And no crypto.

Re: JSON Web Tokens vs. Sessions

#47

Post by nbarbettini » Sat, Jun 18, 2016, 7:31 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…

> The less crypto is being used, the fewer mistakes are being made.

I don't understand this position. What do you mean by "fewer mistakes are being made"?

Re: JSON Web Tokens vs. Sessions

#48

Post by jontro » Sat, Jun 18, 2016, 7:34 PM UTC

btdiehr wrote: post #12

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…

Why do you think you can't invalidate a JWT? Store a JWT that is associated with some object in a database that has the field `isInvalidated`. This isn't rocket science. Sure - this turns the JWT token into a session but there is no way to invalidate based on something that isn't determined at creation time without storing something in a database.

What's the point of using a JWT if so? This effectively converts it into a session token

Re: JSON Web Tokens vs. Sessions

#49

Post by carapace » Sat, Jun 18, 2016, 7:48 PM UTC

Reminds me of "macaroons".

http://research.google.com/pubs/pub41892.html "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud"

Re: JSON Web Tokens vs. Sessions

#50

Post by nawitus » Sat, Jun 18, 2016, 7:52 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…

> 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'.