The arguments here says you can't invalidate a JWT. Exactly!! JWT IS A TOKEN. You can use it for refresh (invalidation & renew) and access (authorization) tokens. There's so much disinformation about JWT. The end result is some not invented here "JWT".
Stop using JWT for sessions (2016)
131–140 of 255 posts
Re: Stop using JWT for sessions (2016)
#132Earlier quoted context omitted.
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) cont…
How you ENCODE data is different from how you TRANSFER data and neither are related to storing state completely on the client vs the server.
You can pass JWTs as cookie data, and you can store nothing but a single session ID in the JWT itself. They are completely orthogonal and have nothing to do with the actual argument. It's misleading when the title and the entire article talks about JWTs vs session/cookies.
Re: Stop using JWT for sessions (2016)
#133I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations.
Regarding session invalidation, I would handle this in two ways.
1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid.
2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS. If your RDBMS goes down, you have much bigger problems. A blacklist will be very short, and often completely empty, so lookups will be significantly faster than checking a session table. You could also use Redis or an application cache for storing the blacklist, with an RDBMS fallback.
Regarding storage, there's nothing stopping you putting your JWT into a cookie with the HTTPonly flag set. So long as you're not storing too much in token, they will be less than 4k and so will fit.
Re: Stop using JWT for sessions (2016)
#134Earlier quoted context omitted.
What if the blacklist becomes unavailable? The author addresses this in part 2.
Then your application is unavailable, just like it would be if your session table went away? I don’t get this complaint. The advantage is that you can use a loosely consistent datastore with expiring entries and few records at any given time. There’s lots to love about the approach.
> Then your application is unavailable, just like it would be if your session table went away?
The author replies: "congratulations, you've just reinvented sessions, with all their problems (like centralized state) and gained nothing in the process", and also with an implementation that is "less battle-tested".
My own opinion: loose consistency can work in some circumstances, but seems a security risk in others.
Re: Stop using JWT for sessions (2016)
#135Earlier quoted context omitted.
How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?
The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If a…
If you need to access the DB to check if you can emit a new SLJWT, what's the point of the LLJWT? Why not just store that UUID by itself?
The SLJWT does seem useful, but 1h seems too much; if I fear someone might be (for example) accessing my email account using a stolen or hijacked device, they can do plenty of damage in that time. Do you make it clear to the user that their request for a remote sign out might take that long to be applied?
Re: Stop using JWT for sessions (2016)
#136Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
This may not be part of the spec per se but you can invalidate them by distributing a bloom filter with revoked tokens and validation times, services just need to poll the service at the granularity needed. This makes scaling still much simpler than one big session store.
Re: Stop using JWT for sessions (2016)
#137Earlier quoted context omitted.
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) cont…
How you ENCODE data is different from how you TRANSFER data and neither are related to storing state completely on the client vs the server. You can pass JWTs as cookie data, and you can store nothing but a single session ID in the JWT itself. They are completely orthogonal and have nothing to do with the actual argument. It's misleading when the title and the entire article talks about JWTs vs session/cookies.
> That has nothing to do with JWTs.
Progress! You're so close to understanding the article.
It wasn't ever about JWTs in particular. It was a response to a widespread engineering antipattern of "storing all session state in a cookie then maybe encrypting or HMACing it so you don't have to store anything server-side". JWT was just how developers tended to implement this antipattern.
Like, literally, that was the entire point of the entire article that Sven wrote.
The examples of apps that do this have become less common since the article was written, so if you're confused by that, you're just missing context, and that's OK.
As for "anti-JWT" arguments, I've made them separately from the argument of Sven's claims. JWT is an error-prone cryptographic design. I wrote a replacement standard called PASETO that doesn't contain these foot-bullets. I still don't recommend people use PASETOs for sessions!
Re: Stop using JWT for sessions (2016)
#138Earlier quoted context omitted.
The author is pretty clearly comparing using jwts with using some framework provided session solution, not having you implement sessions from scratch. So just use a session library with expiration implemented, don’t take one without and add it on yourself.
Again, I’m not arguing that traditional sessions are bad and JWT is categorically good. Of course, if everything is already implemented for you[1], then ease-of-use is less of an issue, but there are valid use cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show). For some of my particular use cases[2], I happen to prefer the JWT approach (despite all the points given in the article,…
> there are valid uses cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show).
The author does sound negative, but doesn't claim JWTs are categorically bad; he actually mentions cases where JWTs are useful: when they are used as single-use tokens. The author claims JWTs as sessions are too problematic to be useful.
> I’ve seen some pretty terrible security issues in both JWT and framework-provided session management libraries.
It seems to me the author is arguing JWTs (used as sessions) are more error prone and less battle tested than traditional session management. So if you've seen terrible security issues...
Re: Stop using JWT for sessions (2016)
#139The arguments here says you can't invalidate a JWT. Exactly!! JWT IS A TOKEN. You can use it for refresh (invalidation & renew) and access (authorization) tokens. There's so much disinformation about JWT. The end result is some not invented here "JWT".
Yes but you're missing an entire chunk of context. The problem mentioned in this article is saying it's bad that you can't invalidate a JWT WHEN using them for authentication and/or authorization. This makes it impossible to do things like disable/kill a session that has been deemed hostile or dangerous (like a stolen account).
Now to build on this, good defense-in-depth can help here. For example if you use JWT only for authn but kept authz 100% server-side. You could then revoke the users access to everything so that the blast radius is confined. The bad actor could still authenticate into the system but would not have access to much or any resources.
Re: Stop using JWT for sessions (2016)
#140An update that has not been added to the article yet due to a lack of time: even if you do have a valid usecase for stateless tokens, you probably want PASETO[1] instead of JWT, due to the inherent cryptographic design flaws within JWT[2].
I'm probably not going to engage in the discussions on here this time, as it was an incredibly mentally draining experience last time; the vast majority of arguments were either already addressed in the article itself (which the commenters clearly had not read and understood in full), or argued against a misrepresented claim. It got so bad that I had to dedicate a whole second article to it[3].
If you have a genuine question or concern about the article rather than an Angry Internet Comment, feel free to e-mail me; my contact details are at the bottom of the article. No guarantees on response time as I'm juggling a lot of other plates at the moment, but I'll eventually get around to responding :)
EDIT: Another addition... this presentation[4] gives some insight into the history of JWT-for-sessions and why it became so popular. A spoiler: it wasn't for rationally-technical reasons.
[2] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
[3] http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...