[fuzzy2]

I’m always amused that with JWT, there never appears to be any separation between JWT-the-storage-format and JWT-what-I-do-with-it. JWT as a storage format is great indeed. If you pin the signing/encryption algorithm. Otherwise you shot yourself in the foot, which is bad, yes.

Everything else isn’t JWT. Sure you can use it with OpenID/OAuth/whatever. Sure you can store them in cookies. Sure you can use them with or without sessions. But how is any of that related to JWT specifically?

One of the articles says with JWT I have to re-implement session management. Just use a different framework then. Sessions with cookies are also not magic.

Another article basically says you don’t need OAuth 2.0 with access tokens and refresh tokens. Very true. Also not about JWT.

[ben-schaaf]

> If you pin the signing/encryption algorithm. Otherwise you shot yourself in the foot, which is bad, yes.

I recon if the library you're using doesn't force you to pin the algorithm (or opt out of pinning), your foot is probably already full of bullet holes.

[jmkni]

Noob question, what is pinning in the context of JWT?

[andreareina]

JWT allows for the tokens to be signed using any of several algorithms, including none[1]. Pinning would restrict this to preferably just one, but at the very least should not allow unauthenticated tokens.

[1] https://tools.ietf.org/html/rfc7518#section-3

[sk5t]

Your question is a good one, and "pinning" is not a very appropriate term here. Whitelist acceptable algorithms by issuer, ok fine--you have to have a library of acceptable public keys or shared secrets to go along with each of the allowed algorithms anyway. The JWT consuming infrastructure here on top of jose4j uses a registry of keyinfo metadata to allow for provision of multiple expirable keys and supported algorithms for each authorized issuer, and I'm not sure why anyone would do it other than that way, really.

Disallowing the "none" algorithm is an important implementation detail, like, maybe your JWT library demands an environment value "JWT_ALLOW_UNSAFE_SIGNING_I_KNOW_WHAT_I_AM_DOING=1" or just doesn't support it in the first place. Maybe it was foolish to ever make any allowance for this in the first place.

[dwaite]

> Maybe it was foolish to ever make any allowance for this in the first place.

Since JWT is used as a wrapper around data, it is possible that your needs will vary based on deployment scenario. In some cases, that data may need to be encrypted, in other cases only signed.

In some cases I may not need integrity protection/repudiation and am already sending over a mutually authenticated/encrypted channel. The implementations may not want signing to be forced on them, impacting their compute/data budgets - but they still want to write their standards to depend on a single data format.

In general there should not be a whitelist, but a precisely known strategy going into evaluation. This is because: - unlike TLS, you likely have a relationship with the issuers - unlike browsers, the different components are being validated against the domain

For JWKS-based distribution, that usually means that a key identifier maps to a specific issuer and to a specific validation strategy. If you supported CA-based trust models, that specific validation strategy should come from the certificates.

You shouldn't look at the public key data and decide based on the algorithm inside the JWT how to interpret it.

[jmkni]

Thanks!

[fuzzy2]

It means to allow only expected algorithms.

Because as critics rightfully point out, without any whitelisting, you can just specify that your JWT does not have a signature and then it’s a valid token, whatever the contents.

[tracker1]

I tend to just implement minimal JWT myself... auth server issues token, all services expect an authentication-bearer header with one. Also, pinning the algorithm and allowed keys is absolutely important.

I'm also not a fan of "sessions" other than at the client, they tend to fail at scale.

[blattimwind]

> JWT as a storage format is great indeed.

RSA or ECDSA with NIST curves for signing things doesn't strike me as "great".

[deathanatos]

If your complaint is that RSA is outdated and ECDSA is backdoored by the NSA, use Ed25519, which JWS/JWT supports[1].

[1]: https://tools.ietf.org/html/rfc8037#section-3.1

[bvrmn]

> JWS/JWT supports

Support for ed25519 signature in current implementations is pretty poor.

[ClumsyPilot]

You can use symmetric, sha256

[bvrmn]

Symmetric signatures completely kill ability to verify token without secret.

For python I had to glue and stick python_jwt with cryptography primitives to do ed25519.

And the most funny thing: very few clients will understand these "standard" JWT tokens.