[schoen]

In tptacek's other post from two months ago:

> For almost every use I've seen in the real world, JWT is drastic overkill; often it's just an gussied-up means of expressing a trivial bearer token, the kind that could be expressed securely with virtually no risk of implementation flaws simply by hexifying 20 bytes of urandom.

This is then to say "generate a random number, give it to the client, accept that same random number in the future as evidence of the client's authorization". A familiar form of that would be a session cookie whose content was generated by a cryptographic random number generator. The session cookie is an index into a database that indicates the properties and authorities that that particular session does or does not have.

Now I guess the reason people may like JWT is that they don't have to have a database or store of tokens that they're issued and what authority each one connotes, because they can verify the signatures on the JWT and then believe the payload. And one system can issue authorizations that another system can consume without direct communication between the two. I think these believing-the-payload properties are a part of what Thomas doesn't like.

[tptacek]

On rare occasions there might be a good reason for stateless auth. I think stateless auth is overused (it's especially funny to see it used on sites that are otherwise dependent on HTTP cookies), but not intrinsically evil.

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.

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