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'm using simplejwt to implement a RP using Auth0 as an IDP, so simplejwt is only used to decode and verify RS256 signed JWTs generated by Auth0. The value of SIGNING_KEY in this configuration should be irrelevant.
The Django Rest Framework docs describe how the authentication classes behave and their return values. They describe describe request.auth as:
The request.auth property is used for any additional authentication information, for example, it may be used to represent an authentication token that the request was signed with.
...
The authentication schemes are always defined as a list of classes. REST framework will attempt to authenticate with each class in the list, and will set request.user and request.auth using the return value of the first class that successfully authenticates.
Developers relying on request.auth for debugging may assume it is safe to call str(request.auth) because it is in copy-pastable form in the django-rest-framework Authentication docs.
However, rest_framework_simplejwt.authentication.Token.__str__ calls TokenBackend.encode() which assumes SIGNING_KEY is set to a key appropriate for the algorithm configuration. If SIGNING_KEY is unset, the key is derived from SECRET_KEY, which is not compatible with RS256:
ValueError: ('Could not deserialize key data. The data may be in an incorrect format, it may be encrypted with an unsupported algorithm, or it may be an unsupported key type (e.g. EC curves with explicit parameters).', [_OpenSSLErrorWithText(code=503841036, lib=60, reason=524556, reason_text=b'error:1E08010C:DECODER routines::unsupported')])
Or, if SIGNING_KEY is set to None:
TypeError: Expecting a PEM-formatted key
In addition to the poor developer experience, this also creates a path for a vulnerability where a naive call to str() could generate signed JWTs when the developer's intention was only consume them.
Proposal:
If SIGNING_KEY is None, Token.__str__ should raise an exception indicating that simplejwt is configured in verification-only mode.
If the token was not created by simplejwt, Token.__str__ should raise an exception indicating that the token is not safe for serialization.
The text was updated successfully, but these errors were encountered:
I'm using simplejwt to implement a RP using Auth0 as an IDP, so simplejwt is only used to decode and verify RS256 signed JWTs generated by Auth0. The value of SIGNING_KEY in this configuration should be irrelevant.
The Django Rest Framework docs describe how the authentication classes behave and their return values. They describe describe request.auth as:
Developers relying on request.auth for debugging may assume it is safe to call
str(request.auth)
because it is in copy-pastable form in the django-rest-framework Authentication docs.However,
rest_framework_simplejwt.authentication.Token.__str__
callsTokenBackend.encode()
which assumes SIGNING_KEY is set to a key appropriate for the algorithm configuration. If SIGNING_KEY is unset, the key is derived from SECRET_KEY, which is not compatible with RS256:Or, if SIGNING_KEY is set to None:
In addition to the poor developer experience, this also creates a path for a vulnerability where a naive call to str() could generate signed JWTs when the developer's intention was only consume them.
Proposal:
Token.__str__
should raise an exception indicating that simplejwt is configured in verification-only mode.Token.__str__
should raise an exception indicating that the token is not safe for serialization.The text was updated successfully, but these errors were encountered: