A Child’s Garden of Inter-Service Authentication Schemes(latacora.singles) |
A Child’s Garden of Inter-Service Authentication Schemes(latacora.singles) |
No wonder it's not well known: it hasn't been picked up by the blog treadmill where dudes on Medium post half-baked info they just found out about, and isn't being pushed by commercial auth proxies.
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?
[1] https://static.googleusercontent.com/media/research.google.c... [2] https://github.com/rescrv/libmacaroons
I'm fucking around, but really the answer is: if we didn't have the presumptive informality of a "blog" or some-such, we just wouldn't write; we'd get 20% of the way through a draft and just pick at it, hoping to make it more correct and authoritative, until our will to keep going evaporated. I have a whole folder full of things I started doing that with.
The in-jokes and snark are what trick us into writing in the first place. There's no getting rid of it.
I'm hopeful that people can at least appreciate that we aren't confining this stuff to Twitter threads anymore.
It may be sufficiently half-baked (not because I'm unfamiliar with the material but because I'm not sure I wrote it for the right audience).
Still feels like we're waiting for another shoe to drop in this space - maybe it really is Macaroons?
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't hold out much hope.
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'd really like to know what alluded potential pit falls are.
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.
When they wish to authenticate a user, they generate a JWT with a user identifier, the client IP address, the Key ID , and the "issued at time". This is then signed using their private key associated with the Key ID. They then provide this to to user's client who then send it us.
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).
The reasons we picked JWT are:
1) We aren'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.
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.
Aside from the issue of trusting our partners not to expose their private key, I'm not sure what the foot-guns are here? (although I am admittedly not an expert)
[1] https://en.wikipedia.org/wiki/A_Child%27s_Garden_of_Verses
1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn't advise forgoing server authentication). That's the beauty of key binding the token. It's useless without the key.
2. It's unclear what the tokbind noun refers to in this paragraph. I'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's stored in a JWT claim or stored in a database table keyed by an opaque oauth token).
3. Anyone can use token binding, not just members of the IETF TLS working group :)
* moving from using client certs to signing exported keying material[0] to prove key possession
* adding support for RSA keys
* adding support for multiple token bindings on a single connection (see referred token binding)
Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.
> In neither case do I anticipate widespread use
For the browser case:
* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).
* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.
* Many compromises happen in the browser so token binding only marginally improves the security of cookies.
I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.
(Incidentally ECDSA really is that much slower, but I appreciate that could be seen as cherry picking because ECDSA is slow even for an asymmetric algorithm.)
I don’t think the argument we’re trying to make is that asymmetric crypto definitionally can’t work. I’m pretty happy TLS exists. Just skeptical that you want to build your s2s auth on it.
client ----- server
req salt -> gen salt
hash sec. <- reply salt
send hash -> remove salt
all good? <- verify hash
It is partially. The problem with the question of what you should use instead of JWT is that it presupposes a usually-wrong assumption that you actually want something of the same shape as JWT, which is usually not true. JWT is a bad answer to the wrong problem: addressing the bad answer part doesn’t address the wrong problem part.
To riff off of jackhammer questions[*], just because chainsaws like PASETO exist and a chainsaw is more effective than a jackhammer at a specific task, doesn’t mean you really wanted a chainsaw.
We will be following up :)
[jackhammers]:
So yes, this is precisely the problem with sending the message 'JWT is bad' when what you really want to send is 'bearer tokens are bad (and JWT is a badly designed bearer token)'.
I am reminded of the situation a few years ago where the message 'stop hashing/salting passwords with SHA1' got widely interpreted as 'Okay, I'll salt and hash with SHA256', when the real message that was needed was to use bcrypt.
But this time I'm not sure there's a bcrypt, yet.
(docs are sparse, I wrote an accompanying doc that might help: https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0N...)
The basic idea is what you described: append only asymmetrically verifiable signatures.
As with most things Macaroons, the harder part is developing a caveat language and verifiers that actually meet your needs. And convincing people that they're a good idea.
That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer.
Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto)
For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here.
With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged).
C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.
We looked at SAML and it didn't seem to be a good fit for our use case. It is overly complex for our needs.
Instead we built a very small subset of what SAML allows, that is very easy to understand and allows our partners to use lightweight JWT libraries with simple APIs instead of trying to figure out how to get a complex SAML implementation to work with our flow.
We didn't re-invent anything. We used an existing, simpler standard for one of it's intended use cases. Our implentation is < 100 lines of code (not including the JWT library which implements the standard).
Edit:
The relevant SAML flow is this:
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-t...
But good luck finding good documentation on it.
https://cs.nyu.edu/media/publications/TR2013-962.pdf
It’s pretty unweildy compared to HMAC construction because:
* each caveat addition requires local generation of a new asymmetric key pair
* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.
* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.
It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.
(Responding to edit)
I can only assume that the most widely-used flow in SAML, the dominant SSO protocol on the Internet, is better documented than the ad-hoc custom version of SAML you reimplemented with JWT. :)
I don't like SAML (I in fact hate it), but the problems I have with SAML are all shared by JWE/JWT! You are describing perhaps the one scenario in all of human experience where I might recommend that someone adopt an XMLDSIG protocol.
JWT has much better documentation than anything I was able to find on SAML, but this may be due to my lack of experience with the domain. I had trouble even finding clear documentation on what the basic structure of a SAML assertion should be. As a developer with limited knowledge of the domain, when picking a tool to solve my problem I default to the simpler tool with more accessible documentation.
The documentation for utilizing our JWT implementation is simpler and more straightforward than what Salesforce provides for it's similar flow implemented with SAML.
> the problems I have with SAML are all shared by JWE/JWT!
And what are those? This was my original question.
This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.
That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?
Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.
Also you should maybe read https://benlog.com/2008/06/19/dont-hash-secrets/
[EDIT:] Actually never mind. I'm sure this is all fine, and look how much more efficient this 3-way back-and-forth conversation is than any conventional auth scheme would be. You should design all your own auth.
But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd like to get the rest of this newsletter.
I would say that jwt is becoming the standard for s2s. I’ve personally worked with a dozen or so corporate APIs that use it and basically all the Microsoft Azure / 365 services are secured with jwt.
I’m intrigued by macaroon because as tptacek points out JWT is easy to get wrong, you’ve got to deserialize json before you can authenticate the request and it’s also tempting to stuff all manner of things into the token claims.
My first pass counterargument to this is: great! You also have FAANG’s security budget and know how to find and resolve bugs like the FB OAuth2.0 tokens being replayable from 1 relying party to another, right? No? Oh.
The general subtext being: that’s nice but you know nothing of their rationale, underlying work that went into securing it, etc; so if you’re picking up a token metaformat without the massive work behind it, you’re just cargo culting.
That said, adequately informing clients of risk and dissuading them from nightmare projects they don't realize are nightmare projects yet is doing your clients a service. Sometimes that means advising them to avoid a feature. Sometimes it means implementing something slightly differently. Most of the time it's not even a trade-off. People use JWTs with just user ids in them, but not necessarily for any particular technical/philosophical reason that you have to address first :-)