[zemnmez]

i think this is conflates the common use of jwts vs their possible use cases. jwts are just standard signed information after all! Open ID Connect, probably the best extant user authentication protocol leverages JWTs to build the ‘ID Token’ that actually encapsulates user identity.

Some conflation between authorisation and authentication here too — the description of JWTs here describes authorisation, not authentication, I think ‘authorizing the client’ vs ‘authorizing the user’ would typically just be ‘authorization’ and ‘authentication’ respectively.

[mswehli]

Well the point is, Authenticating the user happens before the JWT token is issued, and authorizing an action happens after the JWT token is viewed. Authorizing a user on the backend to perform an action is an entirely different thing.

For example, a user signs in and gets a JWT token that has the permission Delete.Everything which in this example is the permission required to delete all a users resources, the client takes this and passes it to the backed. On the backend however, the user might not even be allowed to delete everything. Maybe they're under investigation, or maybe this particular service just doesn't allow it. But its not the role of the JWT to tell you whether or not this particular user is allowed to perform that action, all the JWT token tells you is that this user has allowed the bearer of the JWT token to perform that action on their behalf. But, doesn't mean the user is allowed to perform that action to begin with, so the user has given the client permission to perform an action they themselves aren't allowed to perform.

[zemnmez]

> Well the point is, Authenticating the user happens before the JWT token is issued

In the case of OIDC, the ID Token is the contract of authentication. So when I login via Google, both the consumption of my username / password to produce the ID Token JWT, and the consumption of the ID Token by the third-party are authentication.

> For example, a user signs in and gets a JWT token that has the permission Delete.Everything which in this example is the permission required to delete all a users resources, the client takes this and passes it to the backed.

This is again confusing a common use case of JWT with what it actually is. A JWT is just a signed token. The concept of a 'permission' used here is an abstraction upon what JWT really defines, which are 'claims' (i.e. signed information).

> On the backend however, the user might not even be allowed to delete everything. Maybe they're under investigation, or maybe this particular service just doesn't allow it. But its not the role of the JWT to tell you whether or not this particular user is allowed to perform that action, all the JWT token tells you is that this user has allowed the bearer of the JWT token to perform that action on their behalf.

This is a usage detail for which there are several valid approaches. It's not uncommon to see a JWT used as an authentication token be the source of truth, with only invalidation based on unique id (jti).

The concept of the JWT being correlated with a user authorization is an entirely synthetic one. It's a common use case. Check the original RFC.

> But, doesn't mean the user is allowed to perform that action to begin with, so the user has given the client permission to perform an action they themselves aren't allowed to perform.

Consider this counterpoint: if the JWT itself is not itself a statement of authorization, what's the point in signing it at all? We could just be sending a unique id corresponding to this token (like a circa 200x OAuth token) and get the same effect. JWT is used for a common pattern, but it's important to understand why that pattern is chosen.