[jameshart]

Is this finally the more expansive statement from tptacek than just "Don't use JWTs" that I've been waiting for?

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.

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

[lvh]

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

[dward]

The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).

[evancordell]

I implemented publicly-verifiable macaroons as a PoC and found them reasonably ergonomic: https://github.com/ecordell/watchstander

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

[lvh]

I think there are a few weird incompatibilities between libraries that are likely to bite you unless you have 1 library you use, but generally speaking: yes, figuring out how to structure your claims is the hard part. Most claims are really quite simple, which is why I’m bullish on most tiny startups just sticking a random token in a database and calling it a day.

[ithkuil]

I found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed.

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.

[lvh]

Are you thinking Vanadium or some other spec?

[dward]

Albeit this was years ago but I was referring to the construction linked from the original paper proposed in:

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.