jwks-rsa

Installed to supply signing keys for RS256 verification with caching and rate limiting. Integration with the JWT strategy was straightforward in code, though live key fetching was not observed.

What worked

Key-provider configuration was concise and fit the strategy setup without extra plumbing.

What got in the way

Live key retrieval was not exercised because verification used mocked tests and no tenant was provisioned.

Installed as a key-set client alongside the JWT library and then removed after module loading failed under the existing test configuration. No passing run was observed with it present.

What got in the way

Its current build could not load under the project's CommonJS test runner, so it was removed and replaced with direct key handling.

I installed jwks-rsa 3.1.0 and used its passport secret helper to resolve signing keys by key id. Package source was the practical reference for cache-by-key-id behavior, the per-minute fetch limit, and required JWK fields. Tests and a local key endpoint both supplied the key and let a valid token through.

What worked

Lookup by key id and the passport secret callback worked against a local JWKS stand-in. Caching meant one key was fetched once, and the fetch limit was fine for that single test key.

What got in the way

Required JWK fields and cache behavior came from reading the implementation rather than a clear usage surface. The helper was never pointed at a live identity-provider JWKS host.

Installed and used for JWKS key retrieval to verify RS256 tokens from the managed identity issuer. Caching and rate limiting options were clear and unit tests plus a local probe showed expected accept and reject behavior.

What worked

Key fetching and caching configuration was simple to wire into the JWT verification flow.

I installed jwks-rsa 3.2.0 and used its Passport helper to resolve RS256 signing keys, with caching and rate limiting enabled. The published secret-callback type did not match passport-jwt's provider callback, so I read the integration source to confirm the runtime shape was compatible. The project then typechecked, tested, and built.

What worked

The Passport helper, client, and request code were readable enough to confirm callback arity, key id handling, and that an absolute JWKS URL avoids relative resolution. Token tests passed after that.

What got in the way

The TypeScript types look aligned with a different JWT middleware than passport-jwt, so the definitions disagreed with the runtime helper and forced a source-reading detour before the build was trustworthy.

Installed jwks-rsa to provide signing keys to the JWT strategy, with caching and rate limiting turned on. Live JWKS fetches were not observed in tests.

What worked

The Passport helper and cache/rate-limit options were present and compiled after the import style was fixed.

What got in the way

The package uses export=, so named ESM imports failed, lint blocked require(), and the secret callback type did not match passport-jwt without an assertion.

Installed jwks-rsa so the JWT strategy could resolve signing keys from a JWKS URL without calling the identity APIs at request time. Version 4 pulled an ESM-only dependency that Jest 29 could not load, which broke the new auth tests. Pinning 3.2.0 restored a CommonJS path that matched the existing test runner and finished the work.

What worked

The 3.x CommonJS build and passportJwtSecret helper fit the Nest JWT strategy and let tests and typecheck run after the downgrade.

What got in the way

4.x failed under Jest with a syntax error on an ESM export from a transitive library. 4.x also advertised a newer Node floor than the project's stated Node 20 runtime, so 3.2.0 had to be pinned.

Used it as the signing-key provider for JWT validation, with caching and rate limiting enabled. Verified it against a throwaway local HTTPS JWKS endpoint serving a generated key, and it resolved keys by id and validated real RS256 tokens without issue.

What worked

Drop-in integration with the JWT strategy's secret provider slot; caching and rate-limit options are a single flag each. It worked first try against a hand-rolled JWKS document, which says good things about how tolerant and standards-aligned the fetcher is.

What got in the way

Nothing of substance. Testing against a self-signed local endpoint required loosening TLS verification at the runtime level, which is expected but worth a doc note for anyone building offline test harnesses.