Incompatibility with PyJWT 2.10.0: Non-string identities unsupported in create_access_token

[yoch]

Description

The latest version of PyJWT (2.10.0) introduces changes that prevent the use of non-string identities in create_access_token. This behavior is inconsistent with previous versions and breaks existing implementations that rely on Flask-JWT-Extended's flexibility to handle non-string identity types.

Steps to Reproduce:

1. Install PyJWT 2.10.0.
2. Use create_access_token with a non-string identity (e.g., an integer).

Suggested Fixes:

1. Update the Flask-JWT-Extended dependencies to pin PyJWT to version 2.9.0 in the short term.
2. Update the relevant documentation (e.g., API documentation) to clarify that only string identities are supported with PyJWT 2.10.0.
3. Setting options={"verify_sub": False} that prevents the InvalidSubjectError

References:

• The PyJWT Pull request #1005
• Related issue in PyJWT repo : #1017.

[vimalloc]

Thanks for the report!

I am going to update the documentation and release a new version outlining the difference, but it looks like per the JWT spec sub is mean to be a string, so I'm going to follow suite with the PyJWT change. For now if you're affected by this issue, I would recommend pinning PyJWT to an earlier version, and then updating your application as needed to make sub a string.

[vimalloc]

4.7.0 has been published, which now documents that identity must either a string, or you must use the user_identity_loader to convert your object a string.

If you have issues making this change in your applications for whatever reason feel free to let me know. I think it will hopefully be pretty straightforward, but if you run into any unexpected complexities I would be happy to try and help resolve them with you.

Cheers!

[yoch]

@vimalloc : Thank you for your response and quick reaction !

The current change is perfectly understandable but not very practical. For us, it would require significant changes in our code to switch to string-type identifiers because we rely a lot on get_jwt_identity().

Would it not be possible to either:

1. Store the identifier somewhere other than in the sub claim?
2. Allow automatic deserialization of this identifier so that get_jwt_identity() will returns the expected type?

[vimalloc]

Some options you could consider:

1. Change the identity key to something other then sub via the JWT_IDENTITY_CLAIM option
2. Make use of the user_identity_loader to encode your identity as a string, in conjunction with user_lookup_loader to de-serialize it back to some other object. This would require changing from get_jwt_identity to current_user/get_current_user(). Full docs on this here
3. Pin PyJWT to an earlier version while you work out a migration path to move the data that you are currently putting into the identity into a different claim[s] in the JWT (example), and using get_jwt instead of get_jwt_identity.

Hope that helps!

[yoch]

With the current last version (4.7.1), the simplest solution for us was to set the new JWT_VERIFY_SUB to False.

See: #562 (A big thank to @jlucier for this PR)