mswehli

what does money not spent have to do with anything? it's money that didn't exist that was created. The point of the article wasn't to talk about what causes inflation, its to talk about how inflation is a tax, and the stimulus package turned a period of deflation into a period of inflation.

> The author quote a case where an application have obtained a token on behalf of the user and that's valid too, but it's a less common (in my experience) scenario.

quite common in mine, especially when dealing with service oriented architecture. the public api is given a token, and it should use that token to authorize itself to use other services, or a cron job that performs actions on behalf of users.

> A user token tells you (the relying party) that the user has been authenticated to the satisfaction of the issuer (often Google, Microsoft, Facebook but it can be anyone inclusing your own authority). You can be sure the token has been issued by the issuer due to the signature. If you trust the issuer then you can trust the time-limited token.

But my point is (and the point of the article) is thats not what the token tells you. The token tells you (and the reason its called a bearer token) that whoever holds this token, can perform the list of actions defined within the scopes array. Which is completely different to saying we are 100% sure the user is who they say they are. If the token told you the user is who they say they are, then why do you even need scopes? You could just assume the user is allowed to do anything they wanted to to their own resources.

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