social-core
social-core copied to clipboard
Use a single JWT library
Expected behaviour
Use a single python JWT library.
Actual behaviour
As of now this package relies upon two different JWT python lirbaries:
-
PyJWT
, declared inrequirements-base
file, for the following backends:-
AppleIdAuth
-
AzureADB2COAuth2
-
AzureADOAuth2
-
AzureADTenantOAuth2
-
ExactTargetOAuth2
-
KeycloakOAuth2
-
MediaWiki
-
MicrosoftOAuth2
-
-
python-jose
, declared inrequirements-openidconnect
file, for the following backends:-
Auth0OAuth2
-
ElixirOpenIdConnect
(which derives fromOpenIdConnectAuth
) -
OpenIdConnectAuth
-
Related search: https://github.com/python-social-auth/social-core/search?l=Python&q=jwt
Any other comments?
If there are not any particular need for python-jose
to be used instead of PyJWT
for above listed backends a single JWT implementation should be used as requirements. This will greatly simplify package/requirements management.
Also if there are no need to have two different version of PyJWT
(pyjwt>=1.7.1
in requirements-openidconnect.txt
and PyJWT>=1.4.0
in requirements-base.txt
) a single requirement should be enough..
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Still an issue.
This may be worthy of its own issue, but pyjwt recently had a major version release to 2.0.0
(https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.md#v200) and since the requirements don't specify an upper bound on the version, 2.0.0
gets installed which is incompatible with the code here that use it (I know the apple ID backend breaks).
I'm manually pinning pyjwt in our projects to pyjwt = "==1.7.1"
for now.
@trumpet2012 That’s #532.
@trumpet2012 I suspect the change in 4937977 may fix the Apple ID issue. Can you check it?
@shaib Yep the Apple ID backend works with pyjwt version 2.0.0 after your changes.
@trumpet2012 Thanks, and a happy new year to you too!
The problem is that PyJWT is JWT only library while jose includes JWK (and other modules) as well, which is used in OpenIdConnectAuth. I have no knowledge of these, but switching doesn't seem that straightforward in this case. It might be more reasonable to use jose for all things instead...
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Still an issue.
WTF stalebot?
@omab Maybe it's time to disable stale bot here? If something like this is still desired, we can use https://github.com/actions/stale/, which works more reliably.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Still an issue.
PyJWT from 2.0 has added JWK and support was improved in 2.1.
It should be checked if their implementation could replace jose.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
There have been no releases since the last three times stalebot marked this “stale”. This isn’t helping anyone. Please consider turning stale-bot off.
I was trying to write a PR to handle this by using only pyjwt.
So far the main compatibility issue is https://github.com/jpadilla/pyjwt/issues/314, since jose has builtin-support for this JWT extension required by OIDC but pyjwt no.
If I get some more time I will try to complete this.
A minor update regarding https://github.com/jpadilla/pyjwt/issues/314 which may have bearing on this project:
- https://github.com/jpadilla/pyjwt/pull/773 seems poised to merge (🤞)
- afterwards, I intend to propose a change to make it easier to compute a hash digest from a
pyjwt.Algorithm
object
Those changes will be sufficient to satisfy my use-case, which is validation of the at_hash
claim. I may put in a PR with an example of at_hash
validation to see if I can get that into the docs.
(I'm not a pyjwt maintainer. Just a friendly citizen of the Internet. 🙂 )
I tried to re-take this issue and at the moment I have found these issues:
-
jose.jwt.encode
andjwt.encode
have a couple of subtle differences:- the first calls the first argument
claims
while the latter calls itpayload
(easy to fix) - the first accepts a dict as
key
while the latter only accepts strings (there is an issue where someone asked to support at least their own JWK instances as key) - the first accepts an
access_token
parameter which under the hood calculates theat_hash
claim, the latter require the user to pass theat_hash
in the payload (there is an usage help on how to calculate it)
- the first calls the first argument
- jose and jwt have different claim validation, thus the
JWTClaimsError
of jose can be mapped to a set of different exceptions in jwt (maybe theInvalidTokenError
is the better to get all errors?)
At the moment I do not have enough time to address this, if anyone is willing to do so feel free to code.