Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JWT tokens authenticate the client, not the user

blog.moodio.co.uk

Post reply on HN
Print view View original

11–20 of 24 posts

Re: JWT tokens authenticate the client, not the user

#11

Post by mswehli »

barrkel wrote: post #5

The distinction between client vs user is semantic quibbling - it's not possible to authenticate the user, only the agents, or clients, which act on behalf of the user. We can't interact with the user directly. We can only talk to the user's agent. JWTs just cache the verification of some secret which we hope the user has supplied. What the article actually seems to be asserting is that permission checking should be…

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.

Re: JWT tokens authenticate the client, not the user

#12

Post by barrkel »

mswehli wrote: post #11
barrkel wrote: post #5

The distinction between client vs user is semantic quibbling - it's not possible to authenticate the user, only the agents, or clients, which act on behalf of the user. We can't interact with the user directly. We can only talk to the user's agent. JWTs just cache the verification of some secret which we hope the user has supplied. What the article actually seems to be asserting is that permission checking should be…

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 th…

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

Re: JWT tokens authenticate the client, not the user

#13

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

Re: JWT tokens authenticate the client, not the user

#14

Post by Fred27 »

Fred27 wrote: post #13

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

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.

Re: JWT tokens authenticate the client, not the user

#15

Post by mswehli »

barrkel wrote: post #12
mswehli wrote: post #11

Earlier quoted context omitted.

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 th…

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

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

Re: JWT tokens authenticate the client, not the user

#16

Post by mswehli »

Fred27 wrote: post #14
Fred27 wrote: post #13

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

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 inclusi…

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

Re: JWT tokens authenticate the client, not the user

#17

Post by unscaled »

I've never seen any claims by authors behind JWT claiming the purpose of JWT is limited constrained delegation, and I highly doubt that is the case.

The fact that RFC specifies a subject claim (for the authenticated principal), but not claim for clients or scopes, shows quite clearly that delegation was not the immediate goal behind JWT [1].

JWT and JOSE annoy cryptographers and security researchers so much precisely because they're trying to be a generic cryptographic format that's supposed to solve everything under the sun. The tragedy of JOSE is that instead of trying to solve a small set of problems well, it is basically failing at solving any kind of problem in a satisfactory manner.

JWT can be used in the way described above, but it doesn't seem like particularly a good fit for this purpose. If we can't trust the clients not to lie about their users and their delegated claims, we need to make calls to some mutually trusted STS (or a Token Exchange) anyway. But if we already call an STS, we can just let the STS produce any type of opaque tokens for any type of server and let the backend verify the tokens (delegated or not) with the STS.

[1] Yes, these claims appear in the draft for OAuth 2.0 Token Exchange, but they came a few years later, and that draft is still not standardized.

Re: JWT tokens authenticate the client, not the user

#18

Post by Fred27 »

mswehli wrote: post #16
Fred27 wrote: post #14

Earlier quoted context omitted.

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 inclusi…

> 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 tok…

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.

Re: JWT tokens authenticate the client, not the user

#19

Post by mswehli »

Fred27 wrote: post #18
mswehli wrote: post #16

Earlier quoted context omitted.

> 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 tok…

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.

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.

Post reply on HN