4 ms·
Well, "alg: none" was mandatory to implement to meet the specification, but was not mandatory to accept in use. And most implementations did not include "none"
by quesera 6y ago
Well, "alg: none" was mandatory to implement to meet the specification, but was not mandatory to accept in use.
And most implementations did not include "none" in the default accepted algorithm list.
But yeah, the optics of that debacle were poor. And I can sympathize with those who instinctively avoid JWT due to concern that there are other design/spec flaws lurking.
(JWT is so simple though -- it's what you'd design if you designed a thing for signed, base64'ed messages and then added a couple of extra fields. Some people will respond: "So then do that instead!". :)
IMO, as long as you think of JWT as a simple and standardized signed message format, with broad cross-platform support, it's perfectly suited for its purpose.
- cratermoon 6y agoYou're correct they weren't required to accept "none" unquestioningly. Just that support for "none" was expected. There's lots of possibilities for signed messages to simplify some things that are complicated if tied with maintaining session state on a server.
- nmadden 6y ago“none” has never been a mandatory algorithm. https://tools.ietf.org/html/rfc7518#section-3.1 https://tools.ietf.org/html/rfc7518#section-3.1
- GoblinSlayer 6y agoJWT isn't simple by any measure, just because you have a library doesn't mean it's simple.
- quesera 6y agoHm, that's a surprising take. I think JWT is super simple. One header chunk, one data chunk, one signature chunk. Base64-encoded and concatenated. Done. You don't need a JWT library, although I guess I'm taking JSON parsing ability as a given. This seems reasonable -- anywhere JWT would make sense, JSON is likely established. Some of the other associated standards (JOSE, JWKS, etc) can get complicated, but JWT is about as simple as it gets.