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