[shkkmo]

I don't understand the condemnation of JWTs, this article doesn't seem to explain the condemnation other than saying that "It is extraordinarily easy to screw up JWT." and not to use them.

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)

[tptacek]

So what you're saying is that you re-invented SAML, but with JWT? What you're describing is SAML; every commercial SSO system on the market offers it natively.

[shkkmo]

Our partners are not commercial SSO systems, nor do they all use commercial SSO systems.

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.

[tptacek]

The model that you described is, verbatim, the bearer model of SAML that everybody uses. SAML in theory does more than just that, but the flow you just described is the subset of SAML that every open source SAML library implements. Apart from some minor security controls that you didn't describe and that SAML implements, the only difference is that you built your ad hoc system using JWE, and SAML is built with XMLDSIG.

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

[shkkmo]

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

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.