I am not aware of any spec related to OAuth which requires a server to issue or accept a JWT with an algo of "none". Can you point one out to me?
From the AS side, our product won't even allow you to "sign" a JWT with a value of none. I'm not sure about other authorization servers.
And I always recommend that if a resource server ever sees an algorithm of "none" it should throw out the JWT full stop.
> It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature.
What is the way around this? Looks like Paseto tokens (an alternative I've heard mentioned) works by not allowing unsigned tokens: https://github.com/paragonie/paseto
Is there another way to fix this?
> There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good".
Spooky! Can you share these so I can stay far away from them? :)
There are libraries that allow Bad Things, though, and best practice now is just to ignore the `alg` field. As the github repo you linked says, "There have been ways to exploit JWT libraries by replacing RS256 with HS256 and using the known public key as the HMAC-SHA256 key, thereby allowing arbitrary token forgery."
Which spec are you referring to? 7519? Per section 6 ( https://tools.ietf.org/html/rfc7519#section-6 ) "none" is an optional feature of JWT.
I am not aware of any spec related to OAuth which requires a server to issue or accept a JWT with an algo of "none". Can you point one out to me?
From the AS side, our product won't even allow you to "sign" a JWT with a value of none. I'm not sure about other authorization servers.
And I always recommend that if a resource server ever sees an algorithm of "none" it should throw out the JWT full stop.
> It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature.
What is the way around this? Looks like Paseto tokens (an alternative I've heard mentioned) works by not allowing unsigned tokens: https://github.com/paragonie/paseto
Is there another way to fix this?
> There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good".
Spooky! Can you share these so I can stay far away from them? :)