Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

111–120 of 255 posts

Re: Stop using JWT for sessions (2016)

#111

Post by shusson »

rusk wrote: post #82
abledon wrote: post #68

Earlier quoted context omitted.

How the heck did JWT get such a following with issues like these?

Having recently joined a project that uses JWT (I was completely ignorant of it beforehand - cookies all the way ), I can say that a key advantage is convenience for developers and testing. Once you have the secret for signing you can pretty much access any of the application without having to jimmy the access-controls. I guess that could be a weakness too, but in my experience in fast moving commercially driven envi…

> JWT (I was completely ignorant of it beforehand - cookies all the way)

JWTs can be stored in cookies. So I don't understand why you say this.

Re: Stop using JWT for sessions (2016)

#112

Post by manigandham »

bsamuels wrote: post #107
manigandham wrote: post #103

Earlier quoted context omitted.

Yes you can. JWTs are just a standard way to encode state, and can just as easily be sent as a cookie or the Authorization header. How you invalidate either is the same, whether its a database lookup or something else. Article and most of the comments are wholly inaccurate.

adding a database lookup is adding state

The point is that JWTs are irrelevant to this discussion. How you pass data between client and server can be cookies, or another header. How you encode that data can be JWTs or your own format. It is not either/or.

Whether you manage state 100% on client or share it between client and server is an entirely separate topic.

Re: Stop using JWT for sessions (2016)

#113

Post by vegardx »

tptacek wrote: post #88
vegardx wrote: post #61

Earlier quoted context omitted.

The reality is that hardly anything needs to be instant. You're powerless in the time period that you're setting. You don't need to have Reddit-scale traffic to have to consider this, but when you deal with a lot of backend systems it can reduce complexity a lot.

Isn't this like the one component of an application design where you really do need it to be instant? People get confused because invalidation doesn't happen often. But you also don't use a fire extinguisher often, and you get those checked all the time to... wait, bad example.

I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough.

That said, I don't think a lot of people really take this into consideration when they use a stateless JWTs, or the computation required to issue really short lived tokens.

Aaaand now I have to check my fire extinguisher.

Re: Stop using JWT for sessions (2016)

#114

Post by jcadam »

I use JWT for authentication on my current project. And I eventually ended up having to check the user's 'role' in the database for authorization before I let them do anything anyway (and consequently, revoking someone's user role or suspending their account has immediate effect).

I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it just looked insane to me.

Ultimately, I think what I ended up with is only a minor win over just generating random tokens and maintaining a "sessions" table. Probably not worth the effort and likely won't use JWT again.

Re: Stop using JWT for sessions (2016)

#115

Post by manigandham »

CiPHPerCoder wrote: post #109
manigandham wrote: post #103

Earlier quoted context omitted.

Yes you can. JWTs are just a standard way to encode state, and can just as easily be sent as a cookie or the Authorization header. How you invalidate either is the same, whether its a database lookup or something else. Article and most of the comments are wholly inaccurate.

The whole point of the "JWT for Sessions" design was to prevent server-side storage. Otherwise, they could just use a long random string and maybe HMAC it and call it a day.

Perhaps, but what they actually are is a standard way to encode some data. Whether that's a single number or entire user session state is up to you. And how you pass that data back and forth is up to you.

There are some common usage conventions but the limits described in this article are completely arbitrary.

Re: Stop using JWT for sessions (2016)

#116

Post by CiPHPerCoder »

manigandham wrote: post #110
CiPHPerCoder wrote: post #104

Earlier quoted context omitted.

> This is just FUD. No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclusive. > JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. The difference is this: - Sane sessions - Random unique identifiers stored in a cookie - Upon receiving th…

As stated, how you encode state is different from how you transfer state. It's not an engineering argument if you don't understand the fundamentals. JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use cookies to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server for further validat…

It sounds to me like you don't understand what Sven is arguing against in the article.

> JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use "cookies" to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server.

This is totally irrelevant!

Does your cookie (JWT, PASETO, or whatever) contain more than just a unique identifier?

The argument is: Are you storing things like user_id=13455&is_admin=false in the cookie instead of having that entirely server-side? Don't do that, it's a bad design, store that server-side instead.

That's literally the argument.

Re: Stop using JWT for sessions (2016)

#117

Post by mgraczyk »

Like many other articles on JWTs, this one mischaracterizes the trade-offs that exist.

You can invalidate individual JWTs, you simply store the blacklisted token IDs in a table in your database. Implemented naively, this results in a request flow in which the database is still accessed on every request, defeating one primary purpose for using JWTs. However, there are better ways.

Since the blacklist is just a collection of random token IDs, it isn't sensitive. You can store it anywhere, including in memory in your web servers or in a distributed cache. You can wait during blacklist/token invalidation events until the newly blacklisted token has been propagated.

Using the above, JWTs enable a design space trade-offs that doesn't exist with session tokens. You trade slower blacklist requests (logout, one time confirmations, etc) and minor auth complexity for one fewer db access per request, more flexibility, and more uniformity if you use oath or similar.

All of this is around 90 lines of python in my Django site.

Re: Stop using JWT for sessions (2016)

#118

Post by franciscop »

donatj wrote: post #54
franciscop wrote: post #46

If an attacker can read the user's localStorage you have much bigger issues to worry about: XSS, physical access, no TLS, etc. With any of those, the token is the least of your concerns; an attacker can make API calls, read the data, etc anyway, no matter if its JWT or sessions. So, IF (which is a big if) you implement everything correctly then you have to do two "extra" steps with each tech: - Blacklists (or Whiteli…

"If an attacker can read the user's localStorage" 9/10 the attacker is the user.

Since the topic is authentication, that is an independent concern, right?

Edit: unless you mean something about making the user do something. If it's running a script, it's the same in both ways. Now, if it is about the user retrieving and sending the token, the attacker could still ask the user to manually get the session cookie or the localStorage JWT. The cookies might be protected not to be accessible from JS, but they are still in the browser.

Re: Stop using JWT for sessions (2016)

#119

Post by CiPHPerCoder »

manigandham wrote: post #115
CiPHPerCoder wrote: post #109

Earlier quoted context omitted.

The whole point of the "JWT for Sessions" design was to prevent server-side storage. Otherwise, they could just use a long random string and maybe HMAC it and call it a day.

Perhaps, but what they actually are is a standard way to encode some data. Whether that's a single number or entire user session state is up to you. And how you pass that data back and forth is up to you. There are some common usage conventions but the limits described in this article are completely arbitrary.

Nobody here was arguing about what JWT is, the article is about how they're often abused in an attempt to obviate server-side persistent data storage in pursuit of "scalability".

The title is "Stop using JWT for sessions" not "Stop using JWT".

The arguments against JWT themselves are wholly separate: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

Re: Stop using JWT for sessions (2016)

#120

Post by nine_k »

indeyets wrote: post #90
nine_k wrote: post #69

Earlier quoted context omitted.

I generally agree, but to me "short-lived" would be below a minute. The point of the short-lived token is to make many clustered requests (as when a page loads a lot of assets) cheap because you only need to check a token. Any other human interaction, which takes longer, should go through the server-persisted session logic.

hi ;) I guess that depends on exact use-cases. Below-a-minute is fine for tightly controlled environments, but publicly-used web-apps usually have a sweet spot with TTLs between 10 and 60 minutes. More requests = shorter TTL, less requests = longer ttl (as it would be counter-productive to have more auth-requests than data-requests)

Indeed hi! :)
Post reply on HN