You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I feel this is contradictory with the assessment made for the following older issue , which allowed a more free form typ header. At any rate if we can encode a jwt with typ other than jwt , we should be able to decode the generated jwt.
Can you maybe validate typ header as a string with a reasonable max length instead ? or maybe accept any string with "mime type format" as valid. This make sens as , according to https://www.rfc-editor.org/rfc/rfc7519#section-5.1 :
The "typ" (type) Header Parameter defined by [[JWS](https://www.rfc-editor.org/rfc/rfc7519#ref-JWS)]
and [[JWE](https://www.rfc-editor.org/rfc/rfc7519#ref-JWE)] is used by JWT applications to declare
the media type [[IANA.MediaTypes](https://www.rfc-editor.org/rfc/rfc7519#ref-IANA.MediaTypes)]
of this complete JWT.
I would be happy to make a PR in this direction.
The text was updated successfully, but these errors were encountered:
I noticed the following behavior while trying to validate third party produced tokens. It seems that the only allowed value for the
typ
header isjwt
. This is due to the following https://github.com/authlib/joserfc/blob/main/src/joserfc/jwt.py#L109I feel this is contradictory with the assessment made for the following older issue , which allowed a more free form
typ
header. At any rate if we can encode a jwt with typ other thanjwt
, we should be able to decode the generated jwt.Can you maybe validate
typ
header as a string with a reasonable max length instead ? or maybe accept any string with "mime type format" as valid. This make sens as , according to https://www.rfc-editor.org/rfc/rfc7519#section-5.1 :I would be happy to make a PR in this direction.
The text was updated successfully, but these errors were encountered: