JSON Web Tokens vs. Sessions • Hacker News Board

Re: JSON Web Tokens vs. Sessions

#71

Post by jcoffland » Sat, Jun 18, 2016, 9:05 PM UTC

Alex3917 wrote: post #57

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 reas…

Your missing the whole point. If the server was to track password_last_changed it might as well just track user_currently_loggedin.

Re: JSON Web Tokens vs. Sessions

#72

Post by jcoffland » Sat, Jun 18, 2016, 9:10 PM UTC

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…

This is exactly right. Many people confuse this problem with solutions that involve storing state on the server. Doing so completely misses the whole point of RESTful authentication.

Re: JSON Web Tokens vs. Sessions

#73

Post by StevePerkins » Sat, Jun 18, 2016, 9:10 PM UTC

moyok wrote: post #21

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…

Ehh... but at least for Google's implementation, you won't have a refresh token in the first place if the user doesn't grant "offline access" on a special page that comes up after login.

In our usability testing, we've found that this freaks a lot of people out and reduces adoption. The benefits of basically outsourcing our session management to Google don't outweigh this... so we use JWT for auth only, and then use that token as a session key for our own local solution.

Re: JSON Web Tokens vs. Sessions

#74

Post by jcoffland » Sat, Jun 18, 2016, 9:11 PM UTC

kensign wrote: post #63

btdiehr wrote: post #12

Earlier quoted context omitted.

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.

use a ttl on like a cache store, such as redis

Yes, but this is still a deadend.

Re: JSON Web Tokens vs. Sessions

#75

Post by iheartmemcache » Sat, Jun 18, 2016, 9:13 PM UTC

skylan_q wrote: post #44

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 w…

Re-issuing tokens sounds like a poor-man's nonce. I skimmed the pseudo-code in their paper, immediately said to myself 'uhh..', then a section later they addressed my 'uhh..' by admitting replay attacks are effectively trivial.

In some cases, no security is better than bad security, because at least your users are aware of the insecurity. (Granted, you're protecting against the replay attack - my point still stands for anyone even considering implementing something based on that paper.)

Re: JSON Web Tokens vs. Sessions

#76

Post by StevePerkins » Sat, Jun 18, 2016, 9:18 PM UTC

jcoffland wrote: post #69

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…

"1. Re-authenticate from the browser every hour and store a new JWT token, which is kind of an awful user experience" The old token can be used to request a new token with an extended expiration, before it timesout. This can easily happen behind the scenes, so it does not affect the user experience at all. The real problem is that you cannot enforce logouts. If you just accept that you cannot 100% enforce logouts and…

Right. You can't logout, and you can't extend the expiration time without the user granting an "offline access" scope during the login process.

So WHY exactly is this better than a simple distributed session store (e.g. Redis or whatever), with a browser header or signed cookie as the cache key? That's the underlying premise of all this recent discussion that eludes me.

It seems an argument could certainly be made that you don't need to use sessions if you don't need sessions. But you kinda DO need sessions if you do need sessions. I think all of these recent blogs hand-wave over that, and much of the recent "JWT instead of sessions" chatter is people just repeating a mantra that they read in blog posts because it seems like the hot new mantra.

Re: JSON Web Tokens vs. Sessions

#77

Post by sk5t » Sat, Jun 18, 2016, 9:21 PM UTC

arnarbi wrote: post #66

carapace wrote: post #49

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

It's unfortunate that the JWT encoding scheme of the signed data (non-normative JSON -> base64 -> concatenate with a dot) does not lend itself well to hash-chaining. JWTs could have been a great standard encoding for macaroons. (disclaimer: I'm an author of that paper)

Solid point... I suspect many of the shortcuts in JWT (e.g., not making any attempt to normalize / canonicalize before signing) are a backlash against the implementation headaches of SAML, specifically XML-DSig and the troubles associated with "tell me the ID of the signed element and I'll verify it's signed" mode operation.

Re: JSON Web Tokens vs. Sessions

#78

Post by iheartmemcache » Sat, Jun 18, 2016, 9:22 PM UTC

wtbob wrote: post #30

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 ce…

SPKI was deprecated for SDSI[1] (also done by Rivest), both of which AFAIK haven't been touched in ~20 years (which is fine by me, if the theory and implementation are solid, but SDSI has CORBA/J2EE smells all over the RFC from what I remember. Lightweight, eh...)

[1] https://people.csail.mit.edu/rivest/sdsi11.html

Re: JSON Web Tokens vs. Sessions

#79

Post by joepie91_ » Sat, Jun 18, 2016, 9:44 PM UTC

atombender wrote: post #51

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…

The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not.

What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authorization token for a session on a stateful service.

In none of those three cases do you use the token as the session. Tokens are handed out on a single-use, as-needed basis.

Re: JSON Web Tokens vs. Sessions

#80

Post by joepie91_ » Sat, Jun 18, 2016, 9:46 PM UTC

nbarbettini wrote: post #47

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"?

Cryptography-related code is incredibly easy to fuck up, and the tiniest mistake can completely break your security model. A mistake that could be insignificant in other kinds of code, could easily be critical in crypto-related code.

Thus, you reduce both the amount of mistakes and the impact of mistakes by avoiding crypto where possible.

EDIT: Yes, this includes using existing libraries. It's not just the implementation of the primitives themselves where issues occur.