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.<p>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).<p>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.<p>The claims might be stale, but we have the same problem for revoking JWTs.
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.)<p>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.
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.<p>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].<p>JWT and JOSE annoy cryptographers and security researchers so much <i>precisely</i> 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.<p>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.<p>[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.
> 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.<p>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.<p>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.<p>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.
> Blog posts, sign-up pages, and other reading material can't be tried out, so can't be Show HNs.<p>From <a href="https://news.ycombinator.com/showhn.html" rel="nofollow">https://news.ycombinator.com/showhn.html</a>
Edit: The title has removed show hn now<p>> JWT tokens authenticate the client, not the user<p>I think it's both. It just doesn't <i>authorize</i> the user for anything special.
This is kind of a mess. The title says it authenticates the client not the user, but it doesn't actually talk much about authn. What it actually seems to argue (with some detail, but incomplete to remotely make the case) is that the JWT should be used only to validate user->client authz, not user authz.<p>It fails to really do this, as it notes some IAM systems can be used to transmit user authz information in it, and it provides no substantive <i>reason</i> to reject that use, it just asserts that it's wrong and that there are (unspecified) better alternatives (which it also fails to explain how they are better concretely.)<p>Waving a hand at more efficient and secure is nice, but show me a concrete security concern or evidence that another way is more efficient given that I'm already paying the cost to decode and parse the JWT and maybe I'll believe you.
If 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?) ?
i 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.<p>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.
permissions are regularly included in scopes and you should be driving access based on permissions, not roles, roles are just a bucket for permissions.