> A good app contract will specify which algs and header parameters are accepted, and discard all JWTs that don't match these rules, before passing the JWTs for validation to the library.
While this is ideal it's not always practical for authorization servers that need to support a wide array of algs and header parameters. This is also why - in addition to a good app contract - these token should be proof tokens at multiple layers - including mutual TLS. Aloha, Jim On 10/5/16 7:11 PM, Vladimir Dzhuvinov wrote: > Hi Maciej, > > Apps must not accept arbitrary JWTs, neither let the JWT header alone > drive the JWT validation process. > > A good app contract will specify which algs and header parameters are > accepted, and discard all JWTs that don't match these rules, before > passing the JWTs for validation to the library. > > > On 03/10/16 18:46, Maciej Kwidzinski wrote: >> Hi, >> >> Tim McLean describes an attack vector on JWT-protected services in his >> blog post: >> https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ >> >> The culprit is relying on the algorithm in the JWT header. The >> workaround/recommendation is to ignore the algorithm from the header >> and use a predefined one. >> >> The current RFC 7519 does not address this vulnerability. >> Will this problem be addressed in the standard? >> >> Best regards, >> Maciej Kwidziński >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth -- Jim Manico Manicode Security https://www.manicode.com
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
