A Child’s Garden of Inter-Service Authentication Schemes

* 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.

[0]: https://tools.ietf.org/html/rfc5705

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.

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)

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 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.