21–30 of 70 posts
This is badly written? I was gonna try to argument but it just sound like the writer had a bad day configuring a project IAM and put a generic rant online about JWT usage... If your frontend application connects to multiple protected APIs, you just can't use a session. That's it. Mobile apps and some specific web application need this a lot. The only true claim I see in this post is > almost every developer shipping…
And don't pretend that the 2 are not related because typically an OIDC provider is the thing issuing those JWTs.
So, can you simplify, sure. And now every part of your application needs access to that same table of sessions to get revocation.
It works fine for simple applications not for large solutions with many different systems that cross org boundaries. Because in a lot of orgs the boundaries of the services are more organizational than technical. If you want to be the one that makes them all depend on your SPOF, go ahead, I want to see you sell that idea to your CTO
I mean, honestly, there are really only two options here:
1. You don't know how to "tune" the LLM output, or
2. The LLM output can't be tuned.
Either one means that you should probably write your own thoughts and not have a probabilistic generator create this word-salad that I found extremely hard to follow!
Typical production architecture would look like - frontend only ever sees an opaque session cookie - bff stores the access token against session and attaches it when calling backend services
Yes, storing JWTs directly in the frontend client is a bad idea but surely there is a better way of communicating that than "JWT is a scam and your app doesn't need it".
> RS256 verification is in the same order of magnitude as a Redis lookup
But the point is that the verification is CPU bound and local to the service - which means that it is horizontally scalable.
JWT can be short-lived, for example 1 hour. Then on each request if the token is nearing expiration you decide whether to extend it or not, and if so return a replacement JWT with extended expiration. With a short-lived JWT you don't need to invalidate the JWT. > just put the JWT in an httpOnly cookie You can have two cookies, one that is signed and httpOnly, and another that is unsigned and readable by JavaScript. B…
Let's say a friend sends you an exe file, a game they made. You run it, and immediately realize it wasn't actually your friend. The attacker has stolen your JWT session cookie. The attacker hasn't done anything yet - they are configuring their browser cookies to match yours. You go to invalidate your session / change your password, but it doesn't help. The attacker has a full hour to do whatever they want on your acc…
That's a narrow scenario isn't it, if you have to "immediately" realize?
The uses described in the article assume that authorization of access to resources is handled in some way external to the JWT. This literally takes a system designed to support authorization, ignores that, and uses some other back-end authorization mechanism.
One of the most important features of JWT is its support for capability security[1], via signed claims. If you're just using JWT to authenticate, you're kind of missing the point.
> The payload usually holds a user id, an iat, an exp, a jti, maybe some scopes.
This demonstrates the point nicely. At best, scopes provide some sort of broad authorization such as "read" or "write". But what if you want to prevent IDOR attacks[2] at a low level in your system, to eliminate any possibility of developers accidentally allowing them? Tokens with nothing more than scopes don't help with that at all.
All you need to do to solve that is to add the entity types and IDs that the bearer is authorized to access. So if they're going to a page that displays an invoice, then in the JWT claims you include "invoiceId" (often along with some kind of type field, like "type": "invoice".) The target page checks that the JWT matches the requested resource, and that can indeed be done without any further back-end verification. You would also typically include a tenant ID and other such authorizing identifiers.
Doing this alone will give a system stronger security than 99.9% of systems out there.
Regarding revocation, the point about the above approach is that the tokens are essentially single-use: they authorize access to a particular resource for a short period of time. Basically, whatever the normal "log user out after inactivity" timeout is, the token expiry should be no longer than that.
If you create tokens valid for days or weeks, that's a mistake. You can prevent this simply by giving devs a library that creates the tokens according to org policy.
So yeah, JWTs purely for authentication and doing authorization some other way is a dumb idea, but that doesn't make JWTs a scam, that makes the user ignorant of their real purpose.
[1] https://en.wikipedia.org/wiki/Capability-based_security
[2] https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire...
Eh. JWTs are super handy if you have a single web experience spread across multiple backend apps on the same domain, with a single SSO server to set up the user auth. Definitely not for storing anything sensitive, but treating it like a fancy session cookie with the minimal amount one needs to securely access resources - customerId or whatever - makes life a lot easier than trying to wire up cookie / session manageme…
How that is possible, when every web framework has a package for handling sessions, and in a secure manner. Rolling everything on your own is time consuming and error prone. I know you should not use library for everything, but this is solved problem for a long long time (like crypto), and just using of the shelf solution is right choice to me. You can set the session to be across multiple subdomains and it will work…
This is badly written? I was gonna try to argument but it just sound like the writer had a bad day configuring a project IAM and put a generic rant online about JWT usage... If your frontend application connects to multiple protected APIs, you just can't use a session. That's it. Mobile apps and some specific web application need this a lot. The only true claim I see in this post is > almost every developer shipping…
Why would you want to deal with a bespoke session and authentication table when there's a standard solution out there already? What's the point in figuring out your custom little cookie signature system when every frontend and backend under the sun have a solution ready to go? And somehow, somewhere, Redis is now part of the design to prevent having to do a database round trip for every cookie?
Sounds to me like this is a whole load of work for little benefit. Sure, session cookies just work most of the time, but they have their own disadvantages.
The only tangible benefit to session cookies is that you can log out all existing sessions at the cost of doing a lookup for every request. Most websites don't even offer that functionality, though.
> You can't [invalidate a jwt]. That's the answer. The token is valid until it expires, full stop. The only way to invalidate it is to store the jti server-side in a revocation list and check that list on every single request.
...So the article says you can't invalidate a jwt, and not 2 sentences later, tells you how you can. Of course you can.
> [misc criticisms of refresh tokens]
Mostly agree with this part.
> RS256 verification is in the same order of magnitude as a Redis lookup. And you still have to parse JSON, validate exp, validate iss, validate aud, walk the JWKS cache for the right key, and allocate a few objects the GC has to clean up later. Multiply by your request rate.
I think this misses the mark a bit. Signing/validating a jwt can be done entirely on your application server, which should easily scale horizontally. Any kind of db lookup requires a roundtrip/bottleneck which introduces complexity. So, even if it's the same # of ms, there's still an inherent advantage for validating on your application server IMO.
> Almost no one does [front end verification]
Sure, agreed, but so what? It's a feature that no one uses. That doesn't invalidate other features of jwts.
> The advice goes: don't put the JWT in localStorage because XSS will steal it — put it in an httpOnly, Secure, SameSite cookie so JavaScript can't touch it. Read that sentence one more time. You have just described a session cookie. The browser attaches it automatically, the server reads it on every request, the client can't see what's inside.
Yes, I think from a client perspective, it's fine to think of it like just a session cookie. As many other commenters have pointed out though, it's like a session cookie _with super powers_ because once the request is validated by some kind of front end app server, you can pass that same token around to other backend server and trust the claims inside it and save each of those services from having to do their own lookup. This I Think is the real value of JWTs over plain ol' session cookies.