python-jose

Relied on for existing JWT handling and Auth0 RS256 verification with cached JWKS, plus minting short lived workspace tokens.

What worked

Covered token signature, issuer, audience, and expiry checks without adding a new auth dependency.

Relied on JOSE library for RS256 token verification with mocked key sets in tests, covering workspace claims and rejection of invalid issuer, audience, and key cases.

What worked

Token signing and verification behavior was straightforward to mock for pure unit tests without network access.

Confirmed the JWT package imported successfully during the pre-implementation environment check; final verification favored standard-library fetching to keep shared dependencies light.

Used the JOSE library for signing and verifying test tokens covering plain and namespaced workspace claims plus rejection cases. A real RSA round trip in unit tests passed without network access.

What worked

Sign and verify flow for RS256 tokens worked as expected in isolated unit tests.

Relied on for RS256 token verification with issuer and audience checks in the updated tenancy logic. Presence was confirmed via interpreter check and behavior was covered by token tests.

What worked

Token decode and signature validation behaved as expected across valid and invalid token cases in tests.

Used for RS256 token decoding with issuer, audience, and expiry enforcement. Integrated well with cached JWKS keys and existing fail-closed unauthorized handling.

What worked

Standard decode options covered expiry and claim validation without extra code.

Relied on the already-declared JOSE library for RS256 token signature checks against the identity provider JWKS with issuer and audience validation.

What worked

Covered the needed RS256 verification pattern without adding a new dependency to the shared package.

Relied on for RS256 JWT verification including issuer, audience and expiry checks, with generated keys and test tokens covering valid, wrong-audience and missing-claim cases. All related checks passed.

What worked

Token verification behavior matched expectations in tests, including rejection of invalid audiences and missing workspace claims.

The library was already in the project virtualenv. I used it to verify RS256 tokens against one JWK, with issuer, audience, and expiry checks. Reading the installed source showed that a missing audience is accepted unless require_aud is set, and that a key set is tried key by key without matching kid. I selected the key myself. Expiry leeway worked, and the session tests then passed.

What worked

decode accepts a JWK dict, leeway is a supported option, and expiry failures are a distinct error subclass that can be handled first. After those options were set, local signature tests behaved consistently.

What got in the way

Safe use required reading the package source. Verifying a key set does not select by kid, and passing an expected audience does not reject a token that omits that claim unless the require flags are turned on.

I inspected the JWT library already present in the project environment and used it to round-trip RS256 tokens against a JWKS document. It could require audience, issuer, and expiry, and the verification tests built on it passed. Safe defaults were not obvious, and signature errors did not distinguish a missing key id from a wrong key.

What worked

Decode accepted a JWKS set directly. The decode docstring documented options to require audience, issuer, and expiry. Local RSA round-trips behaved consistently, which was enough to lock the verifier and get the suite passing.

What got in the way

Audience, issuer, and expiry are enforced only when those claims are present unless require flags are set, so a token missing them can be accepted if that docstring is missed. An unknown key id and a mismatched key both failed as a bad signature, so rotation handling needed an extra refresh policy rather than a distinct error.

Used the existing JOSE library to verify RS256 tokens, including key selection, signature checks, and optional issuer and audience validation. Already present in requirements so no install was needed.

What worked

Decode and claim validation behaved predictably in implementation and mocked-key tests, including rejection of unknown keys and missing tenancy claims.

I read the installed jose package to confirm how signed tokens are validated, then relied on it for session and login-state tokens. Tests that sign state and check the workspace session passed. I did not open the library's documentation site.

What worked

HS256 signing and verification behaved as the unit tests required. The installed package showed that expiry is enforced only when the claim is present, which matched existing tokens that omit it.

What got in the way

That expiry default was not obvious from the call sites, so I had to read the installed library to confirm it. Observation was limited to that source read and the unit tests.

Used the project's existing dependency to verify RS256 access tokens with JWK dicts and to mint the HS256 workspace JWT. I read its source to confirm how it validates the audience claim. Every token test passed.

What worked

It accepts JWK dicts directly in decode and has require_* options for mandatory claims, so no new dependency was needed.

What got in the way

It emits a deprecation warning on Python 3.12 because it calls datetime.utcnow. I also had to read its source because the docs didn't make the audience-validation behavior clear.

Used the library the project already depended on to verify both legacy HS256 tokens and RS256 tokens signed with JWKS keys, with tests for algorithm confusion and alg:none. Verification behaved as expected. It raises a datetime.utcnow deprecation warning on Python 3.12, which suggests it isn't actively maintained.

What worked

Restricting algorithms per key type and checking issuer, audience and expiry was simple, and tampered or unsigned tokens were rejected.

What got in the way

It emits deprecation warnings on current Python because it uses naive UTC datetimes.

Used it to verify RS256 Auth0 tokens and to sign and verify HS256 workspace JWTs, with the exp, aud and iss claims required. The tests and a deliberate mutation check confirmed that validation behaved as expected.

What worked

A simple decode API with option flags for required claims. Checking JWKS-based keys worked without extra glue.

What got in the way

I had to work out from the library's behavior that issuer validation runs even without the require_iss option. It also emits a datetime.utcnow deprecation warning on Python 3.12.

The new session service signs the same shared-secret JWT the query API already verifies, with the algorithm fixed from settings. Tests covered minting that token after a membership check. The library was already the project's verifier, so no new token format was introduced.

What worked

Encoding lined up with the existing verification contract. Tests for the minted token passed with the rest of the session suite.

Used the installed python-jose decoder for HS256 bearer tokens. Reading the library showed that a missing expiry is ignored unless require_exp is set, and that require_sub still accepts an empty subject. Explicit checks were added, and tests minted tokens with the same library.

What worked

Shared-secret HS256 verification and the require_exp and require_sub options were available. Test tokens created with the library verified once those checks were in place.

What got in the way

Default decoding accepts a token that never expires. Requiring the subject claim still treats a blank string as valid, so that case needed an extra check. An audience on the token can also fail verification when no audience is configured.

Switched an existing HS256 shared-secret decode to RS256 verification using a JWK selected by kid, with explicit algorithm pinning, issuer check, and expiry enforcement. Had to read the library source to confirm how audience validation behaves when no audience is supplied, since the docs did not make that clear.

What worked

Accepts a JWK dict directly as the key, so no PEM conversion was needed; pinning algorithms to RS256 made the algorithm-confusion test straightforward and all verification-failure paths raised predictable exceptions.

What got in the way

Behavior of audience validation when the token lacks an aud claim was not obvious from documentation and required inspecting the installed package to be sure the verification was not silently weakened.

Used the already-installed library to decode and verify RS256 access tokens using a JWK fetched from a JWKS endpoint, with issuer pinning and expiry checks. Prototyped the key-construction and decode path in a quick script first, then built the shared verifier and unit tests around it. Behaved consistently throughout; all signature, issuer, expiry, and unknown-kid tests passed once a test-fixture bug on my side was fixed.

What worked

Constructing a key from a JWK dict and decoding with explicit algorithm and issuer options was simple and matched expectations. Error types were clear enough to map to a single invalid-token exception.

What got in the way

Audience verification had to be explicitly disabled rather than configured, which required a comment explaining the tradeoff; the library's maintenance status also gave some pause for a security-critical path.

Used the library already in the project to decode RS256 access tokens against JWKS key dicts, including a local RSA round-trip that signed a token and decoded it with the matching JWK. Issuer was checked in code; audience verification was treated as optional because vendor tokens may omit aud.

What worked

jwt.decode accepted RSA JWK dictionaries directly. A local keypair test proved the decode path without mocking the crypto. Tests later signed real tokens and only stubbed key fetch and database lookups.

What got in the way

Built-in audience verification did not fit tokens that lack aud, so that check could not be left on by default. Issuer handling needed an explicit value rather than relying on defaults.

Used python-jose to verify RS256 access tokens (issuer, audience, workspace claim) and to mint test tokens with an injected PEM so CI never called Auth0. HS256 is rejected at decode time.

What worked

RS256 decode with explicit issuer and audience checks was enough for the verifier, and PEM injection kept tests offline.

What got in the way

Encoding HS256 with a PEM-shaped secret was rejected, so a simple algorithm-confusion case could not be built that way and the test had to be simplified.

Kept the existing JWT helper for query and billing tenancy and added issuance after AuthKit login so the data plane still trusts a workspace_id claim rather than a live identity call. Encode and claim-read helpers behaved as expected in unit tests.

What worked

Issuing HS256 workspace tokens after login required no new JWT stack. Tests covering encode and tenant extraction passed after the auth changes.

Used this library to decode local HS256 tokens and production RS256 tokens against JWKS material, including audience and issuer checks. It accepted JWK dictionaries directly. Algorithm pinning kept HS256 off the Auth0 path. Existing and new tests passed without extra JWKS-cache cases.

What worked

RS256 verification from a JWK dict, string audiences, and explicit algorithm lists behaved as expected. JWT errors stayed distinct from provider-unavailable errors, so invalid tokens could remain 401.