[mswehli]

Well yes, but sometimes its not the user that authorizes the JWT token holder to perform the action to begin with, which is why there is the distinction between authenticating the user and authorizing a service to perform an action. JWT tokens don't tell you what the user is allow to do, they tell you what the service/client is allowed to do on behalf of the user. There still needs to be a seperate check to see if the user themselves are even allowed to perform a particular action to begin with, to have even allowed something else to do it on their behalf, and thats what solves some of the stateness issue, in that, if you have for example an admin, who gets fired, even if they still have a valid JWT token that says the client is allowed to perform certain actions on their behalf, there is still a check to see if the user can perform those actions, so as soon as they are fired or demoted, the backend will instantly stop performing actions on their behalf regardless of what the JWT token says they can do.

[barrkel]

> Well yes, but sometimes its not the user that authorizes the JWT token holder to perform the action to begin with, which is why there is the distinction between authenticating the user and authorizing a service to perform an action.

I think you're talking about delegation now.

> JWT tokens don't tell you what the user is allow to do, they tell you what the service/client is allowed to do on behalf of the user.

This is delegation, not authorization.

> There still needs to be a seperate check to see if the user themselves are even allowed to perform a particular action to begin with, to have even allowed something else to do it on their behalf, and thats what solves some of the stateness issue, in that,

Services which are acting on the user's behalf (delegated) can pass the user's claims through too; can pass the whole JWT through. That services act on the user's behalf with delegated authority is a red herring, as far as I can see.

You can still cache permissions (e.g. role) in the JWT. You don't need to do a separate check using the user's identity, as long as you either have mechanisms to deal with the staleness of the cache, or you're happy that the cache lifetime isn't long enough for it to be a problem (nothing happens instantaneously in distributed systems, after all).

> if you have for example an admin, who gets fired, even if they still have a valid JWT token that says the client is allowed to perform certain actions on their behalf, there is still a check to see if the user can perform those actions, so as soon as they are fired or demoted, the backend will instantly stop performing actions on their behalf regardless of what the JWT token says they can do.

This is why you have things like the Refresh and Access tokens pattern. In the absence of revocation blacklists, claims shouldn't be put into long-lived tokens.

[mswehli]

>I think you're talking about delegation now. > Services which are acting on the user's behalf (delegated) can pass the user's claims through too; can pass the whole JWT through. That services act on the user's behalf with delegated authority is a red herring, as far as I can see.

Whether its delegation or authorization, a JWT access token is the result. Keep in mind this isn't about the mechanism to how the IAM decides whether or not to issue a JWT token and to whom, but just what that JWT token means to the endpoint that will consume the token and decide what to do based on it. > Services which are acting on the user's behalf (delegated) can pass the user's claims through too; can pass the whole JWT through

Services acting on a users behalf should not be resending the same JWT token, if they do you've set it up incorrectly. Each service has its own unique identifier, as part of the audience claim. A service that gets a JWT token with a different identifier should reject it, even if the JWT token is valid.

[SgtBastard]

>sometimes its not the user that authorizes the JWT token holder to perform the action to begin with.

Friend, I've read your comments throughout this thread and it is this point where your misunderstanding starts.

From the OAuth 2.0 RFC:

"Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server."

https://tools.ietf.org/html/rfc6749

There is no situation permissable under OAuth 2.0 where an Authorization Server issues access tokens to access resources held by the resource owner, except where the resource owner has given their explicit approval.

Nor is there a scenario where a user can even be requested to give permission to a client to have greater access than that client should otherwise have.

Scopes allow a resource owner to be granular about what they approve access to.