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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

A Child’s Garden of Inter-Service Authentication Schemes

92 点作者 russjones将近 7 年前

8 条评论

sarcasmic将近 7 年前
If you&#x27;re like me and are wondering what Macaroons are, some searching revealed to me that this is the 2014 paper [1] that introduced them to the public. It&#x27;s a nested, chained HMAC construction that&#x27;s useful for delegation, and here&#x27;s a library and some code examples [2] that one can play with to get a feel for what they do and how.<p>No wonder it&#x27;s not well known: it hasn&#x27;t been picked up by the blog treadmill where dudes on Medium post half-baked info they just found out about, and isn&#x27;t being pushed by commercial auth proxies.<p>On that note, posts by Latacora or affiliated persons, there and here, seem to mix well-researched opinions and advice with in-jokes that are lost on all but other experts, assumptions of an inconsistent amount of domain expertise, and quips that muddy some topics more than a bystander would reasonably expect. Why not be more dry and less wry, include links, and morph the FUD around JWT to something real?<p>[1] <a href="https:&#x2F;&#x2F;static.googleusercontent.com&#x2F;media&#x2F;research.google.com&#x2F;en&#x2F;&#x2F;pubs&#x2F;archive&#x2F;41892.pdf" rel="nofollow">https:&#x2F;&#x2F;static.googleusercontent.com&#x2F;media&#x2F;research.google.c...</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;rescrv&#x2F;libmacaroons" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rescrv&#x2F;libmacaroons</a>
评论 #17299855 未加载
评论 #17302472 未加载
评论 #17302619 未加载
评论 #17304360 未加载
评论 #17301963 未加载
jameshart将近 7 年前
Is this <i>finally</i> the more expansive statement from tptacek than just &quot;Don&#x27;t use JWTs&quot; that I&#x27;ve been waiting for?<p>Still feels like we&#x27;re waiting for another shoe to drop in this space - maybe it really is Macaroons?<p>But since container-driven microservice orchestration is ultimately destined to recapitulate the whole of CORBA and DCOM and therefore probably kerberos and every flavor of PKI ever attempted before it gets blown up and replaced with something leaner and simpler and based on shared secrets again, I don&#x27;t hold out much hope.
评论 #17299740 未加载
评论 #17299891 未加载
shkkmo将近 7 年前
I don&#x27;t understand the condemnation of JWTs, this article doesn&#x27;t seem to explain the condemnation other than saying that &quot;It is extraordinarily easy to screw up JWT.&quot; and not to use them.<p>We use JWTs to provide SSO authentication functionality to partners who wish to take on the responsibility for authenticating their users. I still feel like JWT was the correct choice but I&#x27;d really like to know what alluded potential pit falls are.<p>They provide us with the public key of a asymmetric key pair and we provide them with a key ID to use to identify this key a pair. On our side we associate their key ID(s) with the users they are allowed to authenticate.<p>When they wish to authenticate a user, they generate a JWT with a user identifier, the client IP address, the Key ID , and the &quot;issued at time&quot;. This is then signed using their private key associated with the Key ID. They then provide this to to user&#x27;s client who then send it us.<p>We then verify the recency of the JWT, that the JWT is indeed signed by the private key associated with the key id provided, that the IP address matches the client and that the key ID is valid for authenticating the user associated with the user identifier. If all this checks out, we can create a session for the client (using the standard cookie bearer token model).<p>The reasons we picked JWT are:<p>1) We aren&#x27;t responsible for securing their secret(s) (since we never know them) and they can easily send our their public keys to us via less secure channels. If we get a correctly signed JWT, this proves that either the partner approves the authentication or that they have lost control of their private key (in either case, the responsibility is theirs since we have no ability to generate a JWT signed by their private key). This seems like a big improvement over using a shared secret.<p>2) There are existing libraries for most languages to generate and sign a JWT when provided with a few parameters, this decreases the likely hood that our partners will try to roll their own buggy authentication implementation.<p>Aside from the issue of trusting our partners not to expose their private key, I&#x27;m not sure what the foot-guns are here? (although I am admittedly not an expert)
评论 #17299957 未加载
beeknuckle将近 7 年前
If this is a reference to Maslanka&#x27;s &quot;A Child&#x27;s Garden of Dreams&quot;, I like it. One of my favorite pieces for wind ensemble.
评论 #17299512 未加载
dward将近 7 年前
A couple corrections to the section on token binding:<p>1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn&#x27;t advise forgoing server authentication). That&#x27;s the beauty of key binding the token. It&#x27;s useless without the key.<p>2. It&#x27;s unclear what the tokbind noun refers to in this paragraph. I&#x27;m going to assume that you are just referring to the token binding. A token binding lasts for the duration of a TLS connection (sans renegotiation and resumption which complicate things) and is derived from the [clientrandom,serverrandom,mastersecret] of the connection. The token binding secret is just an RSA or ECDSA keypair, independent of client or server certificates, that is generated when the token is issued. The token is bound to the keypair (e.g. by a hash of the public key that&#x27;s stored in a JWT claim or stored in a database table keyed by an opaque oauth token).<p>3. Anyone can use token binding, not just members of the IETF TLS working group :)
评论 #17299760 未加载
HurrdurrHodor将近 7 年前
I am somewhat surprised by the statements about asymmetric crypto algorithms. Given a good library they don&#x27;t seem more error prone and given many common use-cases they are not significantly slower.
评论 #17302742 未加载
mlakewood将近 7 年前
FYI: The article seems to make a comment that implies that SPIFFE is only available to Kubernetes, this isnt the case and SPIFFE is explicitly designed for heterogenous environments.
评论 #17299070 未加载
bullen将近 7 年前
I just use hashing with single use server salt, why is that not mentioned here. It&#x27;s secure and simpler than everything else.
评论 #17302056 未加载