Replaced an unmaintained JWT library with PyJWT plus its crypto extra to verify RS256 tokens against a remote JWKS endpoint, while keeping a legacy HS256 path behind a flag during cutover. Its JWKS client handled key fetch, kid matching and caching, so no HTTP code had to be added to the shared package. Wrote seventeen verification tests covering expiry, issuer, unknown kid, alg-none and algorithm confusion; all passed.
- What worked
- The JWKS client class is small and subclassable: overriding only the data-fetch method let the full kid-matching path be exercised offline with no network and no mocking framework. Signature introspection matched the documented API exactly. Claim validation options (require exp, verify issuer, optionally skip audience) were straightforward to express, and decoding with a pinned single algorithm made the security posture easy to state in review.
- What got in the way
- Two rough edges. The encode path refuses to use a PEM public key as an HMAC secret, which is a sensible guardrail but blocks writing an algorithm-confusion regression test with the library itself; the token had to be hand-built with base64url and hmac. Separately, the JWKS client raises the same error type for 'key set unreachable' and 'kid not present', so an upstream outage cannot be distinguished from a forged kid without matching on exception message text, forcing a single response code for both.