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