chore: Resolves Issue #92, updates to use transitive dependency explicit by blochs · Pull Request #134 · auth0/auth0-api-python

blochs · 2026-09-29T12:46:30Z

Changes

Replaced deprecated authlib.jose usage with Authlib’s transitive joserfc dependency.

This removes the AuthlibDeprecationWarning emitted by Authlib 1.7+ while preserving existing JWT, JWK, and DPoP behavior.

Additional changes:

No endpoints were added, deleted, deprecated, or changed.
ApiClientOptions now accepts jwt_algorithms, defaulting to ["RS256"].
Access-token verification supports configurable signing algorithms.
DPoP verification remains restricted to ES256.
Updated JWT test utilities to work with joserfc’s stricter header validation.
No UI changes or screenshots are applicable.

Example:

ApiClientOptions(
    domain="example.us.auth0.com",
    audience="my-api",
    jwt_algorithms=["RS384", "RS512"],
)

Alternative approaches considered:

Pinning Authlib below 1.7, which would only postpone the deprecation.
Adding joserfc as a direct dependency, but it remains transitive as requested.
Suppressing the warning, which would leave deprecated API usage in place.

References

Testing

This change adds unit test coverage
This change adds integration test coverage
This change has been tested on Python 3.13.7

Reviewers can run:

PYTHONPATH=src pytest tests/test_api_client.py tests/test_utils.py -q

Result: 210 passed.

The test suite verifies JWT verification, DPoP verification, malformed DPoP headers, configurable algorithms, and existing behavior.

Checklist

I have read the [Auth0 general contribution guidelines](https://github.com/auth0/open-source-template/blob/master/GENERAL-CONTRIBUTING.md)
I have read the [Auth0 Code of Conduct](https://github.com/auth0/open-source-template/blob/master/CODE-OF-CONDUCT.md)
All existing and new tests complete without errors

…explicit and removes the deprecation warning for the authlib.jose library.Signed

blochs · 2026-10-29T13:11:59Z

@kishore7snehil Can we get a review of this please? it's an irritating warning...

kishore7snehil · 2026-10-29T13:42:28Z

@blochs Can you please resolve the conflicts so I can take a look?

Preserve upstream token exchange, organization policy, security validations, and test coverage while retaining JWT algorithm configuration, joserfc access-token and DPoP verification, and matching regression coverage.

blochs · 2026-10-29T13:55:36Z

@blochs Can you please resolve the conflicts so I can take a look?

Done - there weren't any conflicts when I put this up...

kishore7snehil · 2026-10-29T14:01:19Z

@blochs UTs are failing. Can you please check?

Use Authlib 1.6 JOSE on Python 3.9, where joserfc 1.7+ is not available through Authlib. Keep the non-deprecated joserfc JWT/JWK implementation on Python 3.10+ and preserve algorithm restrictions. Fixes PR auth0#134 Build and Test import failure on Python 3.9.

blochs · 2026-10-29T14:05:53Z

@blochs UTs are failing. Can you please check?

It's 3.9 as the issue, which I'm pretty sure is EOL.

kishore7snehil · 2026-10-29T14:53:03Z

+if sys.version_info < (3, 10):
+    from authlib.jose import JsonWebKey, JsonWebToken
+else:
+    from joserfc import jwk, jwt


joserfc is imported directly here but isn't listed in pyproject.toml or requirements.txt. It only arrives through authlib 1.7 and above, and authlib = "^1.0" still allows older versions that don't bring it. On Python 3.10+ with one of those, importing the package would fail.

Should we add joserfc as a dependency for 3.10+, or raise the authlib minimum? WDYT?

3.9 is well past EOL. I'd raise the minimum?

kishore7snehil · 2026-10-29T14:53:03Z

+            if sys.version_info < (3, 10):
+                claims = self._dpop_jwt.decode(proof, public_key)
+            else:
+                claims = jwt.decode(proof, public_key, algorithms=self._dpop_algorithms).claims


On 3.10+ the decoded proof is used as a dict straight away, but joserfc doesn't check that the payload is a JSON object. A proof with a payload of 5, null, true or a plain string gets past decode and then fails in the claims check with a TypeError (for example "argument of type 'int' is not iterable"). Before this change those cases raised InvalidDpopProofError. verify_request only catches InvalidDpopProofError here, so callers would see the TypeError.

Shall we check the result is a dict right after decode and raise InvalidDpopProofError if not? A test with a non-object payload would help too, next to the existing non-object header tests.

kishore7snehil · 2026-10-29T14:53:03Z

            raise MissingRequiredArgumentError("audience")

+        if not isinstance(options.jwt_algorithms, list) or not options.jwt_algorithms or not all(
+            isinstance(algorithm, str) and algorithm for algorithm in options.jwt_algorithms


jwt_algorithms accepts any non-empty strings, so ["none"] or ["RS256", "none"] is allowed. With that config a token with alg: none and no signature passes verification on both the joserfc and Authlib paths (I tried 3.9 and 3.10). The default ["RS256"] still rejects it, so this only happens if someone opts in.

Can we reject none when the option is validated? WDYT?

kishore7snehil · 2026-10-29T14:53:03Z

+            if sys.version_info < (3, 10):
+                claims = self._jwt.decode(access_token, public_key)
+            else:
+                claims = jwt.decode(access_token, public_key, algorithms=self._jwt_algorithms).claims


With joserfc, a JWKS key that has its own alg has to match the token's alg. So jwt_algorithms=["RS384", "RS512"] (the example in the new test) fails with unsupported_key_alg when the key says alg: RS256. The same setup works on 3.9 with Authlib, so the option behaves differently by Python version. I haven't tried this against a real tenant's JWKS.

Is this intended? If so, it needs a mention in the docs.

kishore7snehil · 2026-10-29T14:53:03Z

+        audience="my-audience",
+        jwt_algorithms=["RS384", "RS512"],
+    ))
+    assert client._jwt_algorithms == ["RS384", "RS512"]


This only checks the private _jwt_algorithms attribute, so it doesn't show the option is used when a token is verified. I replaced the decode calls with a hardcoded ["RS256"] on both Python paths and all 470 tests still passed. Dropping the list-type check also left everything green.

Can we add a test that signs a token with RS384 and checks it's accepted only when configured and rejected with the default? generate_token hardcodes RS256, so it would need an alg option.

kishore7snehil · 2026-10-29T14:53:04Z

+        token = jwt.encode(header, proof_claims, key)
+    else:
+        key = jwk.import_key(PRIVATE_EC_JWK)
+        registry = JWSRegistry(


This registry exists only so tests can set odd headers, and it lives in the installed package.

kishore7snehil · 2026-10-29T14:53:04Z

-
 from .utils import calculate_jwk_thumbprint, normalize_url_for_htu, sha256_base64url

+# Python 3.9 resolves to Authlib 1.6 (without joserfc); use its JOSE API there.


This comment joins two clauses with a semicolon.

kishore7snehil · 2026-10-29T14:53:04Z

                 Can be a static list of domain strings or a callable that returns
                 allowed domains dynamically. Optional if domain is provided.
        audience: The expected 'aud' claim in the token.
+        jwt_algorithms: Allowed access-token signing algorithms (default: ["RS256"]).


This entry sits after audience, but the parameter is the last one in the signature. It also doesn't say that an empty list raises ConfigurationError.

kishore7snehil · 2026-10-29T14:53:04Z


        - Fetches OIDC metadata and JWKS if not already cached.
-        - Decodes and validates signature (RS256) with the correct key.
+        - Decodes and validates signature (allowed algorithms, default RS256) with the correct key.


The docstring says "default RS256" without naming the option.

kishore7snehil · 2026-10-29T14:53:04Z

+        ApiClient(ApiClientOptions(
+            domain="example.us.auth0.com",
+            audience="my-audience",
+            jwt_algorithms=[],


There are no bad-input cases here (a tuple, a string, [None]), unlike the parameterized cases in test_utils.py.

kishore7snehil · 2026-10-29T14:59:14Z

@blochs Reviewed the changes and added few comments. PTAL!

…n errors

…y overrides

…PoP payloads

blochs requested a review from a team as a code owner September 29, 2026 12:46

chore: Resolves Issue auth0#92, updates to use transitive dependency …

ff4c63f

…explicit and removes the deprecation warning for the authlib.jose library.Signed

blochs force-pushed the deprecated-lib-warning branch from 064981e to ff4c63f Compare September 29, 2026 12:52

Merge auth0 upstream main and resolve joserfc migration conflicts

202832c

Preserve upstream token exchange, organization policy, security validations, and test coverage while retaining JWT algorithm configuration, joserfc access-token and DPoP verification, and matching regression coverage.

kishore7snehil requested changes Oct 29, 2026

View reviewed changes

blochs added 11 commits October 30, 2026 12:19

refactor: centralize Python-version JOSE backend selection

d13849d

fix: declare joserfc dependency and clarify JWT configuration

501d1d2

fix: declare joserfc dependency and clarify JWT configuration

e67688e

fix: declare joserfc dependency and clarify JWT configuration

0e9d19b

fix: validate JWT algorithms and JWKS metadata, normalize verificatio…

b32f14f

…n errors

test: support alternate JWT algorithms without production JWS registr…

42e209b

…y overrides

test: cover algorithm restrictions, cross-runtime JWKS behavior and D…

7782e9e

…PoP payloads

docs: explain JOSE compatibility and JWT algorithm constraints

529128c

docs: explain JOSE compatibility and JWT algorithm constraints

b4ed67e

build: refresh Poetry lock content hash for explicit joserfc dependency

b80c5c9

style: clarify Python 3.9 JOSE fallback comment

02e40bb


		from .utils import calculate_jwk_thumbprint, normalize_url_for_htu, sha256_base64url

		# Python 3.9 resolves to Authlib 1.6 (without joserfc); use its JOSE API there.

Conversation

blochs commented Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

References

Testing

Checklist

Uh oh!

blochs commented Oct 29, 2026

Uh oh!

kishore7snehil commented Oct 29, 2026

Uh oh!

blochs commented Oct 29, 2026

Uh oh!

kishore7snehil commented Oct 29, 2026

Uh oh!

blochs commented Oct 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kishore7snehil commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

blochs commented Sep 29, 2026 •

edited

Loading

kishore7snehil commented Oct 29, 2026 •

edited

Loading