[unscaled]

Depending on your situation, you've got only 3 reliable options, as far as I'm concerned.

1. You could just generate random session IDs (UUIDs or 128-bit base64 strings) and store them in your database or in a persistent cache like Redis. Most OAuth middleware offer this functionality already. Drawback: Scalability - but in most cases you don't need it.

2. Use an alternative format that doesn't provide all the features of JWT, but provides better security: Fernet or Macaroons. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/rescrv/libmacaroons

You'll need to implement claim validation and expiry validation all by yourself.

Fernet is probably better for you if you don't need the killer feature of macaroon (stacking caveats). The payload can be anything, but if you really like JWT you can always stick a JSON-encoded JWT payload inside the token and use your favourite JWT library to verify it.

If you want to support use cases like delegation or claims verified by third parties, Macaroons are worth a look.

Drawbacks: - Limited programming language support. - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own.

3. Roll your own crypto. This not as bad as it sounds, since you could (and should!) use the NaCl/libosodium primitives. The only difference between NaCl secretbox and Fernet is that the latter includes a timestamp - which you can easily add on your own.

[hdhzy]

> - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own.

That's not true. Macaroons have identifier field. See the Readme doc in libmacaroons [0]. Direct quote:

> The public portion tells us which secret we used to create the macaroon, but doesn't give anyone else a clue as to the contents of the secret.

[0]: https://github.com/rescrv/libmacaroons/blob/master/README

I'd say that the biggest difference between JWT and Macaroons is that Macaroons are on one hand simpler than JWT (only one algorithm allowed) and on the other a lot more flexible. Caveats are just byte arrays and it's up to the user to decide how to verify them. The official docs present simple case of string predicates (user = Alice) but it'd be also possible to use something similar to Bitcoin Script. Of course this flexibility has a price: if using third party caveats (another unique aspect of Macaroons) all services must use the same caveat language.

[unscaled]

Interesting, I didn't realize that. The JWT ecosystem (or JOSE ecosystem to be exact) offers a lot of other machinery beyond just having a key ID for key rotation like JWK and OpenID Connect discovery, but there's nothing preventing you from using the same discovery mechanisms with Macaroons. I'm using these mechanisms already with a variety of other non-JWT implementations.

[hdhzy]

Oh yes, exactly, JWT has a stronger ecosystem. Sometimes I feel like they are aimed at different problems, JWT to replace opaque tokens with stateless ones (but if you want instant revocation it becomes a problem) and Macaroons for delegated access. JWTs can be easily used to replace session tokens while Macaroons work best when you've got your entire architecture designed with them in mind.

Just recently I was thinking that it would be nice if my DNS provider used Macaroons for API access. If I want to limit Let's Encrypt's client's access to just _acme-challenge.example.com I could take the Macaroon from DNS provider that has complete access and limit it to "_acme-challenge" and TXT records only. What is nice with Macaroons is that you can derive sub-tokens offline, just from the master token. Wrapping JWTs in JWTs, while possible, leaves one with the base64-in-base64 matrioshka problem.