Use a single JWT library

[sevdog]

Expected behaviour

Use a single python JWT library.

Actual behaviour

As of now this package relies upon two different JWT python lirbaries:

• PyJWT, declared in requirements-base file, for the following backends:

  • AppleIdAuth
  • AzureADB2COAuth2
  • AzureADOAuth2
  • AzureADTenantOAuth2
  • ExactTargetOAuth2
  • KeycloakOAuth2
  • MediaWiki
  • MicrosoftOAuth2

• python-jose, declared in requirements-openidconnect file, for the following backends:

  • Auth0OAuth2
  • ElixirOpenIdConnect (which derives from OpenIdConnectAuth)
  • 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..

[stale]

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.

[andersk]

Still an issue.

[trumpet2012]

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.

[andersk]

@trumpet2012 That’s #532.

[shaib]

@trumpet2012 I suspect the change in 4937977 may fix the Apple ID issue. Can you check it?

[trumpet2012]

@shaib Yep the Apple ID backend works with pyjwt version 2.0.0 after your changes.

[shaib]

@trumpet2012 Thanks, and a happy new year to you too!

[nijel]

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...

[stale]

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.

[andersk]

Still an issue.

[andersk]

WTF stalebot?

[nijel]

@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.

[stale]

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.

[andersk]

Still an issue.

[sevdog]

PyJWT from 2.0 has added JWK and support was improved in 2.1.

It should be checked if their implementation could replace jose.

[stale]

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.

[andersk]

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.

[sevdog]

I was trying to write a PR to handle this by using only pyjwt.

So far the main compatibility issue is jpadilla/pyjwt#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.

[sirosen]

A minor update regarding jpadilla/pyjwt#314 which may have bearing on this project:

• Expose get_algorithm_by_name as new method jpadilla/pyjwt#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. 🙂 )

[sevdog]

I tried to re-take this issue and at the moment I have found these issues:

• jose.jwt.encode and jwt.encode have a couple of subtle differences:
  • the first calls the first argument claims while the latter calls it payload (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 the at_hash claim, the latter require the user to pass the at_hash in the payload (there is an usage help on how to calculate it)
• jose and jwt have different claim validation, thus the JWTClaimsError of jose can be mapped to a set of different exceptions in jwt (maybe the InvalidTokenError 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.