-
-
Notifications
You must be signed in to change notification settings - Fork 688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fail on encode and decode of bad JWS header values #174
Conversation
The JWS spec: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-4.1.4 States that if `kid` is present then it **MUST** be a string. Currently, the library allows silent creation of invalid JWS (and thus, JWT), as it allows any type for `kid`. This commit adds checks to help ensure output meets the spec. * Add jwt.api_jws.PyJWS._validate_headers for validating JWS headers on encode and decode * Add tests
@gabrielg good catch. @mark-adams this looks good to me. |
|
||
def _validate_kid(self, kid): | ||
if not isinstance(kid, string_types): | ||
raise TypeError('Key ID header parameter must be a string') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should probably use InvalidTokenError
similar to other validation errors.
👍 Once you changeover that exception to be a The only reason we didn't have similar validation in here for that already was that we are preparing full JWK support as part of 2.0, but this seems like something reasonable to add now. Thanks for contributing! |
Cool, changed |
Fail on encode and decode of bad JWS header values
@mark-adams should we release this already? |
The JWS spec states that if
kid
is present then it MUST be a string. Currently, the library allows silent creation of invalid JWS (and thus, JWT), as it allows any type forkid
.Allowing arbitrary types is both against the spec, and has some potential security ramifications that I've seen crop up. Since header values can be used pre-verification (and in the case of
kid
, might be required to verify), some more strictness around them and ensuring they meet the spec makes sense.