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

121–130 of 173 posts

Re: JSON Web Tokens vs. Sessions

#121

Post by lobster_johnson »

kalleboo wrote: post #100
lobster_johnson wrote: post #86

Earlier quoted context omitted.

The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not…

There was a solution to that situation proposed here[0] where you keep using session tokens on the user end (so you can still do stuff like revoke sessions), but convert that to a signed token for all internal API calls. [0] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

Thanks. That's pretty much the solution we ended up with, though the article author doesn't see the whole picture. Asking a central authority to issue single-use tokens for every call will result in a huge amount of unneeded network traffic.

Re: JSON Web Tokens vs. Sessions

#122

Post by orhanhenrik »

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…

And then your non tech savvy mother sends you a link to this cool website, and you're logged in with her credentials..

Re: JSON Web Tokens vs. Sessions

#123

Post by moyok »

madeofpalk wrote: post #120
moyok wrote: post #108

Earlier quoted context omitted.

The point is that it would reduce the DB/cache load, as the refresh token would need to be verified once in a few minutes or so as opposed to verifying it for every request. Regular requests could be authenticated in the CPU itself without having to go through to the DB/cache layer. This means lower latency and reduced load on the DB/cache.

...then make the JWT last as long as the refresh token.

If the JWT is as long as the refresh token, then what's the point of having a refresh token? You would then probably need to get new refresh tokens then to make the session last longer.

The idea is to make the refresh token last for say a few days, and the JWT for say 10 minutes. Now, every 10 minutes the client needs to use the refresh token to get a new JWT. The maximum time a client can have access to the service without a valid refresh token is 10 minutes. All the requests made in this window of 10 minutes would be deemed authenticated by verifying the JWT, and without having to go through the database or cache.

Now, say a user of a web app clicks "log me out from all my devices". The user's access needs to be revoked from everywhere they are logged in. If you invalidate all their refresh tokens, then in a max of 10 minutes they would be logged out from everywhere, as their refresh tokens would no longer work and the JWT duration is only 10 minutes.

This approach is essentially a mid-way or a tradeoff between using traditional sessions and JWT. "Pure" JWT is stateless and hence cannot support individual session revocation. The only way to invalidate sessions in "pure" JWT would be to invalidate the key or certificate used to sign the JWT, but that would invalidate everyone else's sessions as well and hence is not very practical.

Since with this approach you implement sessions plus JWT, it's more complicated than just using sessions. JWT should be used for such applications when the latency or load benefit is significant enough to justify the added complexity. For applications that do not need session revocation, however, JWTs are a convenient way to implement sessions without needing a DB or cache layer.

Re: JSON Web Tokens vs. Sessions

#124

Post by nawitus »

blazespin wrote: post #60
nawitus wrote: post #50

Earlier quoted context omitted.

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

It's subtly different - you can store all the actual data in the token.

Re: JSON Web Tokens vs. Sessions

#125

Post by jcadam »

So, I've started working on a new project recently, and thought I'd use JWT (instead of Ye Olde cookie-based sessions). After working with it for a bit, I've decided that I can probably get away with using it for authentication, but definitely NOT for authorization.

I'm using a kind of RBAC and storing Roles in the JWT just seems like a bad idea. Header size is one issue, but also there is the problem of granting/revoking a role and having that change reflected immediately (rather than waiting on the token refresh window).

So, now my API requests happen thusly: "Ok, I have a valid token for User X, so I accept that this request came from User X. Now, let's check User X's roles in the database to see if they have permission to perform action Y on resource Z..."

Hmm... I'm not sure this feels right.

Re: JSON Web Tokens vs. Sessions

#126

Post by 3pt14159 »

paulddraper wrote: post #109
3pt14159 wrote: post #105

Earlier quoted context omitted.

> despite this disadvantage some applications just cannot afford the load of every single request touching the DB or cache. Disagree. This is one of the simplest things alive to distribute. Split the query from the token do the query in the DB and the token lookup is effectively a distributed hash table lookup (assuming the token is, say, a UUID). Once the DB query comes back store the result pending the successful r…

tiny tokens, but needed for every single operation

Sure, but the really hot tokens could be cached right next to the DB. Plus how many operations is a person doing per second? If its more than a couple you can batch them pretty easily.

Re: JSON Web Tokens vs. Sessions

#127

Post by wtbob »

vmarsy wrote: post #42
wtbob wrote: post #33

Earlier quoted context omitted.

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

There are practical limits, but lightweight JWTs won't run up against them. Heavyweight ones would, of course.

Re: JSON Web Tokens vs. Sessions

#128

Post by wtbob »

iheartmemcache wrote: post #78
wtbob wrote: post #30

Earlier quoted context omitted.

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

> SPKI was deprecated for SDSI

No, it's the other way around: SDSI was deprecated for SPKI, which took a lot of its ideas about naming from SDSI.

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

SPKI is indeed old, but the fundamental ideas are really good, and some of them (the cert calculus) are timeless. It needs a v2.0 to update the recommended crypto, specify some more use cases and so forth. But it's really, _really_ good, far better than XPKI and extremely capable.

And still pretty lightweight.

Re: JSON Web Tokens vs. Sessions

#129

Post by iheartmemcache »

wtbob wrote: post #128
iheartmemcache wrote: post #78

Earlier quoted context omitted.

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

> SPKI was deprecated for SDSI No, it's the other way around: SDSI was deprecated for SPKI, which took a lot of its ideas about naming from SDSI. > 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...) SPKI is indeed old, but the fundamental ideas are really good,…

Hey, if the conceptual grounds are sound, which I'm guessing they are, since... I mean, Ron Rivest, age doesn't quite matter w/r/t the timeless elements. Rijndael is mathematically sound, and honestly I've got more trust in older algorithms than newer ones if only because there's been more time for the populace to vet it[1] presumably fortifying it with time.

All of the resources I've searched for are fairly old, do you have anything more recent that I can read up on? I see a 2006 paper, but not much other than that.

[1] Though I'm well aware that having an open-standard available for a long time doesn't mean squat, as evidenced by Heartbleed-esque bugs.

Edit: Reading the '00 "A Formal Semantics for SPKI" Howell, Katz, Dartmouth. This is what I was looking for.

Re: JSON Web Tokens vs. Sessions

#130

Post by DenisM »

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 entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.
Post reply on HN