I don't understand why you seem to think JWTs can't be used for authorization, and the fact that you denigrate this as a "puppynoob" approach is telling, but not necessarily in the way you think it is.

Many large systems with millions of users (e.g. Google's Firebase) store user claims in the token, and that can (and is) used to validate permissions.

JWT is basically just a signed JSON container format (JWS) with a couple of standard claims and recommended verification procedures. They can be used as a component of an authorization system but they would just be a small component of that. I think the question should be whether JWT is a good fit to play a part in authorization?

If you just need to tack in a bunch of scopes which are configured per clients and are rarely changed, or if you need to track authentication method and time for sensitive operations ("amr" and "auth_time" claims in OIDC), JWT could probably do the job. But for more fine-grained RBAC (or any user-permission-based scheme), JWT is quite problematic.

For one, you will need to revoke the access token every time permissions change. On certain type of systems this could happen quite often (e.g. every time somebody shares a folder with you), and you don't want to constantly log the user out, so all clients would have to have logic to automatically refresh the access token (with a permission-less refresh token) on revocation.

The other option is pure bloat: The moment you go beyond a simple admin flag or a fixed set of roles, you're already on the expressway to a bloated 10kb token. In every system that support a technically unlimited amount of resources and roles, storing all ACLs in the token gets you very large tokens really fast.

JWT can be used to store permission bits, but didn't it properly is very complex topic and usually works well only as "subsetting of claimed userid permission set" or "short lived token to be passed to third party to perform an action on behalf of".

One can do also quite complex system based on taking multiple claims as a whole plus signature, but that's taste in my experience other than stuffing user info into token

> That's what makes JWT-based calls stateless:

> I decrypt it to get the userId, then do the role lookup

A if every auth needs a database lookup then it is not stateless. A JWT is stateless if and only if you trust its signature "offline"

But then how are JWT different from opaque session tokens? Both still need server side checks for anything

The truth is that JWTs have always been meant for authorization, they just were applicable to very few cases almost exclusively at Google scale