JWT tokens authenticate the client, not the user
blog.moodio.co.uk
JWT tokens authenticate the client, not the user
1–10 of 24 posts
Re: JWT tokens authenticate the client, not the user
#2> Blog posts, sign-up pages, and other reading material can't be tried out, so can't be Show HNs.
From https://news.ycombinator.com/showhn.html Edit: The title has removed show hn now
> JWT tokens authenticate the client, not the user
I think it's both. It just doesn't authorize the user for anything special.
Re: JWT tokens authenticate the client, not the user
#3> Blog posts, sign-up pages, and other reading material can't be tried out, so can't be Show HNs. From https://news.ycombinator.com/showhn.html Edit: The title has removed show hn now > JWT tokens authenticate the client, not the user I think it's both. It just doesn't authorize the user for anything special.
Ah thanks.
I disagree though, with JWT tokens and especially assuming you’re using the redirect flow, for the server especially, the server doesn’t need to know if the user was even authenticated as it could be another service calling it, it only needs to know that whoever is calling it is allowed to act on behalf of the user and perform certain actions. An example of this would be if you connect your email to a CRM system, the crm system at that point might have been authorised by the user to send emails on their behalf, or might have been authorised by an admin to send users on everyone’s behalf. In the case where an admin has given permission then the CRM system can send emails on everyone’s behalf even if the user themselves were never authenticated.
I believe it is the role of the IAM provider to authenticate the user, JWT tokens authorise callers to perform actions.
Re: JWT tokens authenticate the client, not the user
#4If you start calling other IAM servers to verify the permissions of the user, aren't you throwing away the usefulness and advantages of the JwT woken being a form of stateless auth (isn't the use case of jwt exactly to avoid calling the IAM upon request?) ?
Re: JWT tokens authenticate the client, not the user
#5The 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 done via calls to an IAM and not via claims in the JWT (if I'm understanding it right).
I don't buy this either. Tokens can cache permissions, albeit with the same staleness issues that JWTs have for authentication. It's not much different than how a driving license is both evidence of identity and evidence of a permission.
The claims might be stale, but we have the same problem for revoking JWTs.
Re: JWT tokens authenticate the client, not the user
#6i think this is conflates the common use of jwts vs their possible use cases. jwts are just standard signed information after all! Open ID Connect, probably the best extant user authentication protocol leverages JWTs to build the ‘ID Token’ that actually encapsulates user identity.
Some conflation between authorisation and authentication here too — the description of JWTs here describes authorisation, not authentication, I think ‘authorizing the client’ vs ‘authorizing the user’ would typically just be ‘authorization’ and ‘authentication’ respectively.
Re: JWT tokens authenticate the client, not the user
#7> there are far more secure and efficient ways of then verifying what the user is allowed to do, such as calling the IAM directly from the backend service or by implementing a more complex permissions service.
Making another call over the network for auth is by definition vastly less efficient by several orders vs having been handed the information in the first place. The bottleneck of a centralized permission service is actually what pushed us to JWT in the first place.
Using JWTs to authenticate the user allows actual decentralization of your endpoints. We have services that speak directly to nothing else in the ecosystem and it’s a major win.
The security argument is valid to a small extent, but I’ll trust a well salted SHA256 with my life until I’m told otherwise.
Re: JWT tokens authenticate the client, not the user
#8> there are far more secure and efficient ways of then verifying what the user is allowed to do, such as calling the IAM directly from the backend service or by implementing a more complex permissions service. Making another call over the network for auth is by definition vastly less efficient by several orders vs having been handed the information in the first place. The bottleneck of a centralized permission servic…
Depends on where the permissions logic is stored, but to add information such as the example of can user a access the data of company x, then the IAM provider has to make a call back to the service where this information is stored. Its unlikely you'd want to store logic like that within the IAM provider, nor is it necessarily possible.
But if you are relying on the IAM provider for user permissions, then you still have the bottleneck of a centralised permission service, its just now your IAM provider.
The only scenario i can think of where its more efficent, is in role based authentication.
Re: JWT tokens authenticate the client, not the user
#9If you start calling other IAM servers to verify the permissions of the user, aren't you throwing away the usefulness and advantages of the JwT woken being a form of stateless auth (isn't the use case of jwt exactly to avoid calling the IAM upon request?) ?
Well no, JWT tokens are there to validate a call can be made. e.g., that whoever has made the HTTP call to your API server has been allowed to do so by the user. JWT tokens aren't there to tell you what the user themselves are allowed to do. What the user is allowed to do is an entirely different thing and you shouldn't rely on bearer tokens to tell you that.
Re: JWT tokens authenticate the client, not the user
#10i think this is conflates the common use of jwts vs their possible use cases. jwts are just standard signed information after all! Open ID Connect, probably the best extant user authentication protocol leverages JWTs to build the ‘ID Token’ that actually encapsulates user identity. Some conflation between authorisation and authentication here too — the description of JWTs here describes authorisation, not authenticat…
Well the point is, Authenticating the user happens before the JWT token is issued, and authorizing an action happens after the JWT token is viewed. Authorizing a user on the backend to perform an action is an entirely different thing.
For example, a user signs in and gets a JWT token that has the permission Delete.Everything which in this example is the permission required to delete all a users resources, the client takes this and passes it to the backed. On the backend however, the user might not even be allowed to delete everything. Maybe they're under investigation, or maybe this particular service just doesn't allow it. But its not the role of the JWT to tell you whether or not this particular user is allowed to perform that action, all the JWT token tells you is that this user has allowed the bearer of the JWT token to perform that action on their behalf. But, doesn't mean the user is allowed to perform that action to begin with, so the user has given the client permission to perform an action they themselves aren't allowed to perform.