Error: Subject must be a string!

[kwagdy]

We have been using flask-jwt-extended to manage JWT tokens for a few months now, we made a quick recent update to a separate part of our code, unrelated to the JWT. However, we started seeing this error Subject must be a string during login phase (and token management), which is fired by the function declared under invalid_token_loader that fires when an invalid JWT is encountered. The error refers to the line set_access_cookies(identity=u_token) in the following code section:

resp = make_response(redirect(url_for("home")))
u_token={}
u_token['user_id']=user.id
u_token['role]=user.role
u_token['c_id]=cAuto.id
access_token = create_access_token(identity=u_token)
refresh_token = create_refresh_token(identity=u_token)

set_access_cookies(resp, access_token, max_age=60*60*24) # <--- Error fires here!
set_refresh_cookies(resp, access_token, max_age=60*60*24*7)

It seems that it expects a string. When we change the passed parameter momentarily to a string, the line passes without error. However, as per the docs, it's ok to add any JSON serializable data to identity:

create_access_token - identity: The identity of this token. It can be any data that is json serializable. You can use user_identity_loader() to define a callback function to convert any object passed in into a json serializable format.

Although we haven't changed any part of the code related to JWT. And the fact that it has been running all the past months without issues. This made our primary suspicion to be one of the dependencies that we might have failed to set a specific version for, in case it was updated recently causing the issue, but it seems we already have the versions in for the JWT related libraries, at least to our knowledge.

This might be a shot in the dark, but we don't see that this might be caused by other libraries at this point, appreciate your help!

For reference here is our requirements.txt:

appengine-python-standard
Flask==2.1.3
gunicorn
passlib
Jinja2
Flask-JWT-Extended==4.3.0
Werkzeug==2.0.0
requests
python-dateutil
google-cloud-logging
google-cloud-datastore
google-cloud-storage
google-cloud-core
iso8601
firebase_admin
reportlab
arabic_reshaper
python-bidi

[nathanganser]

Same issue for us, pretty critical. Still investigating what's going on.

https://pypi.org/project/Flask/#history Flask updated some code recently, might be related to that. still investigating..

[manisandro]

This is due to the just released pyjwt-2.10.0 [1] which adds the sub claim validation [2]. According to the spec [3]

The "sub" value is a case-sensitive string containing a StringOrURI value

so the validation is correct. So either the flask-jwt-extended documentation should be fixed, or JWT_IDENTITY_CLAIM should default to something else than sub, or create_access_token and get_jwt_identity should internally json-serialize/deserialize.

• [1] https://github.com/jpadilla/pyjwt/releases/tag/2.10.0
• [2] Validate sub and jti claims for the token jpadilla/pyjwt#1005
• [3] https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.2

[nathanganser]

So quickfix is to add
PyJWT==2.9.0
at the top of your requirements.txt file

[vimalloc]

Thanks for the report!

I am going to update the documentation and release a new version outlining the difference, but I don't plan to break away from the underlying PyJWT implementation or JWT spec for this case. 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!

[kwagdy]

Oh wow you guys are quite active! appreciate the quick turn around!
We started to convert the identity to string, and we will later move the other claims to additional_claims parameter.
Thank you!