TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JWT tokens authenticate the client, not the user

31 点作者 mswehli大约 5 年前

9 条评论

barrkel大约 5 年前
The distinction between client vs user is semantic quibbling - it&#x27;s not possible to authenticate the user, only the agents, or clients, which act on behalf of the user. We can&#x27;t interact with the user directly. We can only talk to the user&#x27;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&#x27;m understanding it right).<p>I don&#x27;t buy this either. Tokens can cache permissions, albeit with the same staleness issues that JWTs have for authentication. It&#x27;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.
评论 #22341405 未加载
Fred27大约 5 年前
That&#x27;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&#x27;s not the case. (I agree putting user permissions in a JWT is poor design though.)<p>Strictly speaking JWTs don&#x27;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.
评论 #22341927 未加载
unscaled大约 5 年前
I&#x27;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&#x27;re trying to be a generic cryptographic format that&#x27;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&#x27;t seem like particularly a good fit for this purpose. If we can&#x27;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.
donatj大约 5 年前
&gt; 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.
评论 #22341345 未加载
matsemann大约 5 年前
&gt; Blog posts, sign-up pages, and other reading material can&#x27;t be tried out, so can&#x27;t be Show HNs.<p>From <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;showhn.html" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;showhn.html</a> Edit: The title has removed show hn now<p>&gt; JWT tokens authenticate the client, not the user<p>I think it&#x27;s both. It just doesn&#x27;t <i>authorize</i> the user for anything special.
评论 #22341222 未加载
dragonwriter大约 5 年前
This is kind of a mess. The title says it authenticates the client not the user, but it doesn&#x27;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-&gt;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&#x27;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&#x27;m already paying the cost to decode and parse the JWT and maybe I&#x27;ll believe you.
Koffiepoeder大约 5 年前
If you start calling other IAM servers to verify the permissions of the user, aren&#x27;t you throwing away the usefulness and advantages of the JwT woken being a form of stateless auth (isn&#x27;t the use case of jwt exactly to avoid calling the IAM upon request?) ?
评论 #22341370 未加载
zemnmez大约 5 年前
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.
评论 #22341386 未加载
cameronfraser大约 5 年前
permissions are regularly included in scopes and you should be driving access based on permissions, not roles, roles are just a bucket for permissions.