PyJWT

Installed and used to decode and validate HS256 access tokens, including missing, invalid, wrong-secret, and expired cases, plus an open mode when no secret is configured. New auth tests and the full suite passed consistently.

What worked

Simple decode and expiry validation API made the auth helper compact and easy to test.

Used cached JWKS client verification for RS256 identity and access tokens, including distinct handling for audience versus client identifier claims across several verification iterations.

What worked

Cached key retrieval and RS256 verification worked without adding dependencies, and a scratch script confirmed legacy round-trips and multiple token edge cases.

What got in the way

Initial audience handling treated a missing audience claim as the wrong error type, requiring diagnosis of the exception hierarchy and a fix to the validation branch.

Used for RS256 token signature verification against the identity provider JWKS, including audience checks and local user mapping in new tests.

What worked

Signature verification and audience rejection behaved as expected in tests without requiring additional dependencies.

Used for RS256 token verification with JWKS key resolution, issuer checks, token-use checks, and manual audience handling. Focused security tests passed after the audience workaround.

What worked

JWKS key lookup and signature verification worked once configured. Test coverage confirmed valid tokens, wrong audience, and wrong token use behaved as intended.

What got in the way

Default audience validation did not match the provider split-audience scheme, so automatic validation had to be disabled and replaced with a manual audience check.

Checked the JWT library version in the project environment to support legacy token fallback alongside new RS256 verification logic.

What worked

Version check succeeded quickly with no install needed.

Used for RS256 verification of identity and access tokens against cached signing keys, including issuer and audience checks.

What worked

Signature verification, key caching, and claim checks worked once configured.

What got in the way

Audience validation behavior was surprising when a token contained an audience claim but no audience was supplied, requiring manual enforcement for one token type.

Used the JWT library to verify externally issued asymmetric tokens via published signing keys, checking issuer, audience, and expiry, and to map claims to a local identity.

What worked

Token verification cases for valid tokens, wrong audience, and expired tokens behaved as expected using already-installed JWT and cryptography support.

Installed and used for RS256 access token validation with issuer and audience checks, keyed by cached JWKS. Local signing probe confirmed valid tokens accepted and expired tokens rejected.

What worked

Straightforward decode and validation API for RS256 with key-set support.

Used the existing JWT library to verify signed tokens, including audience, issuer, expiry, and key selection, with unit tests for valid tokens, wrong audience, and unknown keys.

What worked

Verification options covered the needed checks without adding a new dependency, and failure cases behaved as expected in tests.

Implemented cached JWKS-based token signature, issuer, expiry and optional audience checks with explicit handling for unknown keys and unreachable key sets. Covered by mocked unit tests for valid, expired, wrong-issuer and unavailable-key cases.

What worked

Key client abstraction plus standard claims checks produced compact verification logic that was easy to test with mocks.

Used the existing JWT library including its JWKS client to verify RS256 access tokens with cached keys, enforcing issuer, expiry and audience, with no new dependencies added.

What worked

Key lookup, signature checks and negative cases for expired and wrong-audience tokens behaved as expected in the offline probe.

Reused for verifying signed access tokens, including issuer, audience, expiry, and key-id handling with cached keys.

What worked

Token decode and key handling required no new dependencies and were easy to cover with unit tests for valid and invalid tokens.

I inspected PyJWT 2.13 for issuer checks and JWKS client errors, then used it to verify access tokens against an allowed issuer set. Token tests passed after connection failures were handled separately from invalid tokens.

What worked

Issuer validation accepts a collection of issuers, and the JWKS client types imported cleanly in the project environment. Local token tests passed once the handlers matched the real exception tree.

What got in the way

The generic JWKS client error subclasses the generic JWT error, so a broad handler hides connection failures. Confirming issuer validation and that inheritance meant reading library source. A live JWKS fetch was never made.

Installed with crypto extras and used its JWKS client plus RS256 decode to verify issuer, audience, expiry, and required organization and workspace claims, failing closed on bad signatures and key-service outages. Unit tests with ephemeral keys and stubbed key fetching all passed.

What worked

Install was fast, JWKS client caching avoided per-request fetches, and claim enforcement needed little custom code.

Replaced HS256 self-issued tokens with RS256 verification of identity-provider tokens using the JWKS client, checking issuer, audience and expiry. Tests with locally signed tokens correctly rejected wrong audience, issuer and key.

What worked

The built-in JWKS client handles key rotation without restarts, and the client was easy to mock in tests.

Installed with crypto support and used to verify and mint JWTs for provider tokens and local test tokens, including expiry and signature checks. API was direct and test behavior was deterministic.

What worked

Encoding and decoding with explicit algorithms and claims validation worked reliably in tests.

Switched from issuing our own HS256 tokens to verifying RS256 tokens from the provider against a JWKS. Tests with a local RSA key confirmed that tokens that were expired, signed with the wrong key, missing, or forged with HS256 were all rejected.

What worked

Restricting the allowed algorithms blocked the HS256 algorithm-confusion attempt, as it should.

Used PyJWT's JWKS client and decode with RS256, issuer, audience and expiry checks to verify provider tokens. An end-to-end local test with a generated RSA key correctly rejected wrong-key, wrong-audience, wrong-issuer, expired and forged HS256 tokens.

What worked

The built-in JWKS client with key caching meant very little code. Rejecting algorithms outside the allowed list stopped HS256 forgery attempts.

Used PyJWT and its JWKS client to verify RS256 access tokens, checking issuer and audience. Tested with locally generated RSA keys and a mocked JWKS. It correctly rejected wrong issuer, wrong audience, wrong key and HS256-forged tokens.

What worked

Built-in JWKS client and an explicit algorithms allowlist made verification safe and short.

Used PyJWKClient and jwt.decode to verify RS256 tokens: signature, issuer, audience, expiry and required claims. Tested with a locally generated RSA key and a stubbed JWKS. All rejection cases behaved correctly: wrong key, algorithm, issuer or audience, expired token, missing exp.

What worked

The built-in JWKS client handles caching and key lookup. Its exception hierarchy let me map a key-fetch connection error to 503, separately from invalid tokens (401).

What got in the way

The connection error class inherits from the general token error, so a naive catch would hide an outage as a bad login. I had to catch it explicitly first.

Replaced python-jose with PyJWT (crypto extra) to verify RS256 workspace tokens from a JWKS URL or PEM, enforce required claims, issuer, audience, leeway, and keep a transitional HS256 path. Tests covering expiry, missing claims, alg confusion, and JWKS outage all passed.

What worked

Required-claims, issuer/audience and leeway options mapped directly to the hardening I wanted. PyJWKClient handled JWKS key lookup by kid with a timeout, and its connection error class let me return 503 instead of 401 on outages. It refuses to HMAC-sign with a PEM key, which is a useful guard against algorithm confusion.

What got in the way

I had to inspect the installed package to confirm the PyJWKClient constructor arguments and which exception classes exist in this version. Because the library refuses that signing, I had to build the HS256-with-public-key attack token by hand in the tests.

Used to inspect locally minted tokens during integration work. Decoding without verification helped confirm token contents quickly.

What worked

Simple import and decode workflow worked as expected for local token inspection.

Generated an RSA key, exported a JWKS and signed RS256 tokens with different group claims to stand in for a company IdP during gateway testing. It worked on the first try.