jose

Installed and imported for signature and claims verification of identity tokens, keeping the service free of custom crypto while supporting fail-closed auth and offline unit tests.

What worked

Install succeeded and the API covered the needed verification path; the full test suite passed with coverage for missing, invalid, wrong-organization, misconfigured, and outage cases.

Used for stateless RS256 JWT verification with cached remote key set and issuer, audience, expiry, tenant and scope checks. Integration passed local unit and service tests with unauthorized and forbidden cases.

What worked

Remote key set with caching avoided per-request identity calls. Claim validation API was straightforward and test coverage for missing, expired and wrong-scope tokens passed.

Installed as the first choice for remote key-set verification and then removed after it failed to run under the existing CommonJS test setup. No passing test or build was observed with it installed.

What got in the way

The installed major version could not run under the project's CommonJS Jest setup, so it was removed before completion.

Added for local Bearer JWT verification with cached remote key set plus issuer and audience checks. Version lookup succeeded and the implemented auth checks passed typecheck and committed tests.

What worked

Cached key set plus claim verification covered the needed security checks without extra network calls per request.

Added as the JWT verification library for RS256 tokens via remote key sets. Installation and local verification path worked cleanly with stubbed tests.

What worked

Small focused API for building login URLs, parsing bearer tokens, and verifying signatures kept auth code isolated and testable with injected verifiers.

Used to validate delegated engineer bearer tokens and extract identity and group claims. Fail-closed behavior in production was straightforward to implement.

What worked

Compact verification API and clear claim extraction made per-call identity checks simple.

Added the JWT library to verify ID tokens inside a small server-side OIDC adapter with sessions, single-use state, and organization checks. Covered URL building, state expiry, org guard, and login callback flows with isolated tests using injected verifiers.

What worked

API covered token verification cleanly without pulling in a heavier OIDC client, keeping the adapter small and testable offline.

Used for remote JWKS creation with caching and local verification of issuer, audience, expiry and scopes in a shared auth package. Integration tests around valid, expired, wrong audience and missing scope cases passed consistently.

What worked

Compact API for cached key set verification and claim checks. Fail closed behavior on missing config was straightforward to enforce.

Installed jose 5.9.6 and used it to verify access tokens locally, checking issuer, audience, expiry, and signature against a cached key set. Typecheck failed because CryptoKey is not exported; switching to KeyLike from the same package fixed that, and the verification tests then passed.

What worked

jwtVerify plus the local and remote key-set helpers covered the checks the service needed, and the library error types were specific enough to map invalid tokens without contacting an identity provider on each request.

What got in the way

Importing CryptoKey from jose failed typecheck. The compiler reported that the module does not export that member, so the tests had to use KeyLike instead.

Installed jose 5.9.6 and used it for in-process RS256 verification against a cached local key set, including issuer, audience, and scope checks plus rejection of unusable keys. Tests covering that path passed. Locating the public types and the JWKS error-code name in the installed package took several reads.

What worked

The verify helper, local key resolver, and stable error codes were enough to keep signature checks off the network, cache keys, and treat a missing key as a distinct failure. The pinned install succeeded on the first attempt.

What got in the way

Declarations were not in the first place checked, and searches of the installed package did not surface the missing-key error code. Confirming the API meant opening generated type files and the error module in the package dist tree.

Used jose to verify OIDC access tokens (RS256) locally against cached JWKS keys, with checks for issuer, audience and expiry. Also used it in a test helper that generates RSA key pairs, exports public JWKs and signs test tokens. All verifier tests passed. The only snag was a type error: the key type referenced the DOM CryptoKey type, which isn't available in a Node-only tsconfig.

What worked

Key generation, JWK export, signing and verification all fit together cleanly, so testing a real token flow didn't need the identity provider. Its error types made it easy to map failures to 401 responses.

What got in the way

Typing a stored private key without the DOM lib meant deriving the type from the return type of the key-generation function. I first planned to stay on the older major version for compatibility, then checked engines and moved to the current major.

Used jose for JWT verification against a remote JWKS with local key caching, restricted to RS256. Tests covering expired, wrong-audience, wrong-issuer, unknown-kid and HS256-rejection cases all passed. To control how the key cache behaves during an identity-provider outage, I had to read the library's compiled source.

What worked

jwtVerify with a remote key set handled issuer, audience, expiry and algorithm checks cleanly. Error classes with stable codes made it easy to map failures to 401 versus 503. Generating local test keys was simple, and it worked well with ESM and TypeScript.

What got in the way

The remote JWKS cache has no built-in stale-while-revalidate or last-known-good fallback. I worked out reload, cooldown and timeout behavior by reading the dist files, then wrapped the key set myself. The package declares no engines field, so Node version support was unclear.

Used jose for remote JWKS fetching and JWT verification in a global API guard, checking issuer, audience, expiry and the RS256 algorithm. In tests I used its local key generation, signing and local JWKS helpers. One package did the work of three passport-based packages.

What worked

Remote and local JWKS sets share one API, so production code and tests used the same verification path. Key generation and SignJWT made it easy to build test tokens for wrong issuer, wrong audience, expired, unknown key and HS256 cases. Typings worked with the existing TypeScript build.

What got in the way

I pinned v5 because I wasn't sure v6 still supports CommonJS, and I worried about loading it under Node 20. I had to work that out myself; it wasn't clear from what was in front of me. In my test helper, calling the claim setters after passing a payload overwrote the claims I meant to test. That was my mistake, but it's an easy one to make with the builder API.

I added jose 6.2.12 so the service could verify access tokens locally against a JWKS and cache signing keys. It installed cleanly with the auth SDK and cookie plugin. No jose-specific error appeared. Automated token checks went through a fixture provider, and I never fetched a live JWKS, so jose's runtime behavior is unrated.

What worked

The pinned release resolved in the same install as the other auth libraries. Local JWT verification with key caching matched the latency needs of the API.

Installed and imported JWT library to verify RS256 tokens via remote key sets and enforce organization scoping with fail-closed behavior. Setup and API use were straightforward and the full test suite passed with no crypto issues observed.

What worked

Remote key handling and verification API avoided custom crypto and integrated cleanly with injectable test doubles.

Used jose to verify signed access JWTs against a remote JWKS, checking issuer and audience, and to sign test tokens with a local key. Missing, forged, expired and wrong-audience tokens were all rejected as the tests expected.

What worked

Remote JWKS lookup and verification took only a few lines, and checking issuer and audience was easy. Signing tokens with a local key for tests worked without trouble.

Used the library to verify signed identity tokens against provider keys and map verification failures to closed access responses, with an injectable verifier for unit tests covering valid, invalid and provider-unavailable cases.

What worked

Key-based verification was straightforward to wrap in a small testable helper, and the full test suite passed without retries after integration.

Installed jose and used its remote JWKS set and JWT verification for a token verifier that pins the algorithm and checks issuer, optional audience, clock tolerance and expiry. Tests used locally generated keys to sign valid, expired, wrong-issuer, unsigned, HMAC-signed and unknown-key tokens, and all behaved as expected.

What worked

Built-in key caching and refetch on unknown key IDs handles key rotation with no extra code. Key generation and signing helpers made fully offline tests easy. Both ESM and CJS builds worked under Node 20 with tsx.

Used jose for local JWT verification against a remote JWKS: issuer, audience, expiry, clock tolerance and signature checks, plus local key generation and token signing for tests. The API was clean and the typed error codes made it easy to map failures to 401 or 503. The one real problem was the remote key set's stale-cache behavior, which I had to work around.

What worked

Verification and signing APIs are concise and well typed. Distinct error codes (no matching key, JWKS timeout, invalid JWKS, generic) made a precise HTTP error mapping possible. createLocalJWKSet and generateKeyPair made a realistic stand-in issuer for tests easy. Reading the shipped type definitions and dist source answered every question.

What got in the way

By default the remote JWKS treats cached keys as stale after a max age and then blocks on a refetch; if the issuer is unreachable, verification fails with no fallback to the last good keys. For a high-traffic API this turns an identity-provider outage into an API outage. I wrapped it with a never-stale cache plus background refresh. A built-in stale-while-revalidate option would help.

Used jwtVerify with createRemoteJWKSet to check issuer, audience and expiry, and used SignJWT and generateKeyPair to mint test tokens and a fake IdP.

What worked

Clean API with typed error codes for claim and signature failures. Easy to build a test IdP.

What got in the way

A JWKS fetch failure comes through as a plain error with no code, so my first error mapping reported IdP outages as invalid tokens. It doesn't refetch keys when the kid matches but the signature fails, so test servers needed a restart after the keys were regenerated.

Used for JWKS-based JWT verification in each server and for signing test tokens with a local JWKS. Straightforward API, no problems.

Added this JWT library to validate signatures via cached JWKS plus issuer, audience and expiry checks, merging scope and permissions claims for route guards.

What worked

Lightweight pure JavaScript validation with cached keys added only sub-millisecond overhead in design and passed type checks and the full local test suite.

Used it to re-verify the caller's JWT against a remote JWKS in the request interceptor and to extract claims such as groups, scope and auth time. Unit tests covering spoofed and expired tokens passed.