I don't get it. Why were you lying to people??? Why were you pretending? Thats not healthy and pretty anti-social.

> 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. Both contain the same information. So JavaScript can read the information in the second cookie, but since it is unsigned, exfiltrating the cookie doesn't compromise security.

If you drink all of the koolaid, you can wind up with a system where two different parties securely authenticate sessions without any kind of secrets ever needing to be provided directly. Both parties generate and retain private key material in an HSM and perform signing ops there. The only thing that has to be trusted is the subject of the certificates. Keys can be rotated arbitrarily and the counterparty should not have any issues with this, assuming the standards are followed.

Short lifetime is the best solution to concerns around revocation. The vendor I last integrated with has their opaque tokens expire after 15 minutes. Immediate revocation sounds preferable but in practice there are other controls that will typically compensate for any gaps here (i.e., audit logs & the police). If you are firing someone and you think they might do a really bad thing that the business could never recover from, you should probably disable their accounts about an hour before the call with HR.

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 it has no idea why.

That's the true problem. JWT is being used as a SSO strategy in the wrong way most of the times.

The article doesn't need clickbait titles either, which is also not a savory practice. Other than that it is good to educate people to make informed decisions on JWT.

No, the rest of the post was written by an LLM.

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.

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