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

81–90 of 173 posts

Re: JSON Web Tokens vs. Sessions

#81

Post by joepie91_ »

aleem wrote: post #18
tootie wrote: post #6

If you need to validate the Authorization header on every request that's not really different than using session tokens we've been using for the past 15 years. JWT is just a formalized way of managing cookies. Which is nice and I like it, but it doesn't actually enable anything that couldn't be done before albeit with a more ad hoc approach.

Right, Signed Cookies. JWT doesn't make the claim that it's a new concept, you are assuming as much. It's a standard and as you correctly gleaned and like most other standards, comes with a lot of benefits, best practices, is battle tested and ready-to-use in your favorite frameworks. It becomes even more useful if you application serves multiple clients such as browsers, iOS applications and so forth because you can…

Both browsers and mobile frameworks can deal with session cookies just fine. JWT doesn't solve anything there.

Re: JSON Web Tokens vs. Sessions

#82

Post by joepie91_ »

palmdeezy wrote: post #45

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?

The two are not mutually exclusive. Either way, my article (http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...) argues neither.

Re: JSON Web Tokens vs. Sessions

#83

Post by joepie91_ »

hharnisch wrote: post #35
hharnisch wrote: post #34

JWT is especially useful for validating requests in a microservice architecture. You can pass around the token an embed roles in them. No need to keep a session store with them!

On another note I've been working on a service that generates expirable/refreshable JWTs. Its a good way to start trying them out https://github.com/hharnisc/auth-service

Better remove that again. It is extremely dangerous to store any kind of credential in Local Storage. Cookies are the (only) correct place for storing credentials.

Re: JSON Web Tokens vs. Sessions

#84

Post by stephenhuey »

StevePerkins wrote: post #76
jcoffland wrote: post #69

Earlier quoted context omitted.

"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 th…

Another benefit is providing a standard way to access multiple services at once with a single token. It is possible to force a logout on the server side if a problem arises, and you wouldn't need to store these invalidated tokens in the database because it'd likely be a small blacklist you make available to all the servers (and a blacklisted token would be in that list only until the expiration time).

Re: JSON Web Tokens vs. Sessions

#85

Post by StevePerkins »

stephenhuey wrote: post #84
StevePerkins wrote: post #76

Earlier quoted context omitted.

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

Another benefit is providing a standard way to access multiple services at once with a single token. It is possible to force a logout on the server side if a problem arises, and you wouldn't need to store these invalidated tokens in the database because it'd likely be a small blacklist you make available to all the servers (and a blacklisted token would be in that list only until the expiration time).

> access multiple services at once with a single token

If you're talking about multiple microservices under your own control, then they could all work with your distributed session store just as easily (if not more so).

If you're talking about SSO across multiple third-party services, then perhaps JWT could be a nicer solution than SAML. However, here you're talking about a single-digit percentage of edge cases. Not enough to declare "JWT over sessions" as a general rule.

Re: JSON Web Tokens vs. Sessions

#86

Post by lobster_johnson »

joepie91_ wrote: post #79
atombender wrote: post #51

Earlier quoted context omitted.

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

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 heard the term "direct-to-database" before, but we've been doing it for about 6 years, albeit not using Firebase, and it's huge win over the classic "custom, ad-hoc API per use case" methodology. Exposing a shared data layer abstraction between microservices is no different than exposing a more targeted API (i.e. there's conceptually zero difference between "POST /objects/42" and "POST /users/42"), including as far as security is concerned.

Re: JSON Web Tokens vs. Sessions

#87

Post by userbinator »

Bino wrote: post #17

Why the obsession with 3 letter short names? Why "typ" and not "type". I'm sore the overhead can be ignored and the parser doesn't care.

...and then it goes and uses JSON, which is definitely not the most compact of serialisation formats. The whole thing is base64'd anyway, so something like ASN.1 PER which is a "true" binary format would be far better than base64'ing what is essentially text. But then, in my experience, Web standards tend to be weird like that.

Re: JSON Web Tokens vs. Sessions

#88

Post by spriggan3 »

lobster_johnson wrote: post #86
joepie91_ wrote: post #79

Earlier quoted context omitted.

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

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…

> Central session stores don't scale with distributed architectures.

Sessions stores scale as much as anything else.

Re: JSON Web Tokens vs. Sessions

#89

Post by spriggan3 »

aleem wrote: post #18
tootie wrote: post #6

If you need to validate the Authorization header on every request that's not really different than using session tokens we've been using for the past 15 years. JWT is just a formalized way of managing cookies. Which is nice and I like it, but it doesn't actually enable anything that couldn't be done before albeit with a more ad hoc approach.

Right, Signed Cookies. JWT doesn't make the claim that it's a new concept, you are assuming as much. It's a standard and as you correctly gleaned and like most other standards, comes with a lot of benefits, best practices, is battle tested and ready-to-use in your favorite frameworks. It becomes even more useful if you application serves multiple clients such as browsers, iOS applications and so forth because you can…

Your IOS application can use sessions and cookies. There is nothing magic about sessions and cookies.

Re: JSON Web Tokens vs. Sessions

#90

Post by spriggan3 »

scope wrote: post #65
zatkin wrote: post #8

Aren't cookies the safest approach for storing authorization tokens? I recently found out that both Google and Facebook use cookies for authorization, so it seems like the way to go, though I've read that it gives programmer headaches.

Cookies can be/are used for extensive tracking (even when you're not techically on the site). The EU requires websites that use cookies to display conformation message on how cookies will be used to track the user.

The infamous "cookie" law isn't limited to Cookies. JWT, local storage and co all fall under the same law that will force you to put a disclaimer on your webpages. There is absolutely no difference between the 2 in that regard. The fact that you think otherwise is a serious legal risk for your business if you have one.
Post reply on HN