[qyv]

> But there can be no reasonable argument for a standard conceived of in the last 10 years to allow users to deploy something for which the payload chooses the cryptographic interpretation of the payload. No application anyone on HN is deploying needs user-selectable cryptography. This is never a feature; it's only ever an invitation to horrible vulnerabilities.

When I read about JWT's I saw the alg fields to a simple indicator of the algorithm being used on the JWT, not that it is allowing the token to select whatever algorithm it wants for the server to run. Granted, this is a semantic difference, but if you treat the alg field as such it then becomes the servers choice of what algorithms to support. The practical solution is simple: Only support one algorithm, and if the token's alg does not match what the server is expecting, do not authorize. Sure this is a weakness in the JWT spec, but the real underlying issue is dev's not understanding the security mechanisms and libraries they are deploying. That is bad news no matter what tech they are using.

[stouset]

If you leave the `alg` field out, the exact same scenario occurs: someone sends you a token, and you fail to authorize using the server-side configured algorithm. Having this field adds nothing of real value.

The only thing having an `alg` field does is make the standard trivially misusable by well-intentioned developers.

[unscaled]

Well, practically every JWT library developer thought otherwise, because they'll all verify the JWT based on the alg field, which means every careful implementation of JWT must validate "alg", but I'm afraid there are too many developers out there who don't.

Realistically speaking, it looks like JWT won the popularity race and IETF unfortunately won't deprecate the algorithm header anytime soon, so we should at least try to campaign library maintainers to have the algorithm field ignored by default and use the algorithm specified by client code instead.