[Fred27]

That's a really poor and incorrect blog post. The author has a very poor understanding of JWT, has described just one small use case, has decided this is the only one and thinks everyone else has misunderstood them. That's not the case. (I agree putting user permissions in a JWT is poor design though.)

Strictly speaking JWTs don't have to be used for authentication at all. They are just signed tokens containing JSON. You could have a shopping list in there if you wanted to be sure it was definitely your wife telling you to pick up milk on the way home.

[Fred27]

Sticking with security though - a JWT certainly can be used to identify a user. 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.

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.

As far as how the issuer has confirmed the user's identity and whether it represents a person, service, etc. can vary.

There 's obviously way more to federated authentication that I want to post in a comment, but there you go. I believe the OP was getting slightly confused between some OAuth2 implementations and proper security implementations like OpenId Connect.

[mswehli]

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

[Fred27]

That's really not what scopes are for either. There are a few people on this thread who are trying to politely explain that you haven't quite got what can be a reasonably tricky subject. You'd be well advised to step back a bit and read up on OpenID Connect rather than just digging in on your position and insisting everyone else is wrong.

[mswehli]

Ok... Getting a bit rude, so if you prefer we can end the discussion here, however first lets take a look at 2 links: https://oauth.net/2/scope/ "Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account."

Literally the first sentence in the definition. If you prefer take a look at the definition on OAuth definition at https://auth0.com/docs/scopes/current/oidc-scopes. Now which part of that exactly anything about authenticating the user or goes against what i've said? You'd be well advised to take your own advice.

[Fred27]

> if you prefer we can end the discussion here

Yeah - let's do that. You're now quoting things that directly contradict your position, so I'm starting to think we're all just being trolled.