@ChronoDK The "sub" claim if present should indeed be a string according to the JWT RTF:

The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL. SOURCE

So in that sense the validation logic is correct to throw an error. As for all other JWT claim validations, these validations are turned on by default (see #1005), so I can imagine it might have broken some code. In case no sub claim is provided in the JWT payload, the validator should still pass though.

I'm not author that built this functionality, but I was suggesting the 2.10.0 version number in my PR, to get some of the new functionality available through an official release. So my apologies if the version number created the wrong expectations, and broke any code. To go back to the old behaviour of 2.9.0 and below, just add the following as @WolfgangFellger already suggested:

my_jwt = "JWTGoesHere"
jwt.decode(my_jwt, options={"verify_sub": False, "verify_jti": False})

Or start using the new validation functionality:

my_jwt = "JWTGoesHere"
my_expected_subject = "someSubject"
jwt.decode(my_jwt, subject=my_expected_subject)

Uh oh!

sub must be a string now? #1017

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions