[lvh]

I’m not ‘tptacek but I am a Latacora principal.

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]:

[jameshart]

Apologies for misattribution :)

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.

[tptacek]

That argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats.

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.

[jameshart]

I'm not really looking for a comprehensive argument against JWTs (they're a terrible solution to the wrong problem is a reasonable enough argument); I am looking for a path to move the conversation forward from 'Well OAuth2 supports JWTs as a way to authenticate without making a callback to the auth server, and we know we shouldn't try to roll our own scheme so HMAC(timestamp) seems a bit hacky, and macaroons seem halfbaked, and cert management gives me nightmares, so isn't just using what OAuth2 provides the safest option? After all, everybody else is doing it...'

[pvg]

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?

[sytringy05]

Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request.

Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.

[pvg]

Right, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths.

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.

[sytringy05]

No, I meant in the context of server to server comms, as well as end user authn/authz.

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.

[lvh]

I flubbed the link to jackhammer questions last night: http://bash.org/?866112