Passport

Installed as the underlying authentication middleware for JWT bearer validation. Setup was straightforward once paired with the framework adapter and JWT strategy package.

What worked

Standard bearer-token delegation worked in tests without custom session handling.

Installed to validate RS256 access tokens against issuer, audience, and key identifier. Configuration for token extraction and key lookup was clear for the intended managed-identity flow.

What worked

Token verification options mapped directly to the expected domain and audience settings.

Used with the JWT strategy to validate bearer tokens and map claims to a staff user object. Setup required issuer, audience and key retrieval configuration, but request enforcement and unauthenticated rejection behaved consistently in tests and a live boot probe.

What worked

Bearer validation and claim mapping integrated cleanly with framework guards.

I installed Passport 0.7.0 as the middleware layer under the NestJS passport integration and the JWT strategy. Request authentication in the test suite and on the running server succeeded with it on the path. No Passport-specific failure appeared.

What worked

Once the strategy and guard were wired, Passport stayed in the background and the bearer check completed for both rejected and accepted calls.

I installed Passport 0.7.0 as the strategy runtime under the NestJS adapter. Most of the API stayed behind that adapter. I kept a separate Passport type package because the JWT strategy types expected it. Authenticated and unauthenticated request tests passed.

What worked

The strategy name and bearer flow behaved consistently once the NestJS wrapper was in place, and the test suite covered both rejection and a valid token.

Kept the existing Passport JWT strategy as the auth gate while returning translated unauthorized errors. Compatibility with Passport mattered more than custom bodies; live 401 responses were not inspected.

What worked

The existing strategy still authenticated requests and could read a locale claim during validation without a new auth stack.

What got in the way

Guards wrapping the strategy may swallow a translated HTTP exception and emit a generic unauthorized response, so API error wording is not clearly under the catalog on that path.

Extended an existing token strategy to pull a locale claim off the verified payload and stash it on the request so later layers can read it, which required switching the strategy to pass the request into the verify callback. Verified it compiles against the typings; never exercised with a real token in this environment.

What worked

Opting into receiving the request in the verify callback is a single option flag, and the callback signature change typechecked without casts or overload fights, which I had expected to be a problem.

What got in the way

The ordering guarantee I actually needed — what runs when the token is rejected before the verify callback is ever called — is not obvious from the typings and had to be reasoned out, with a header fallback added to cover it. I could not confirm the live path without a real signed token.

Used passport-jwt with a JWKS secret provider to validate RS256 access tokens from issuer and audience claims. ExtractJwt and Strategy were enough for a Nest PassportStrategy. Type definitions for secretOrKeyProvider did not match the JWKS callback shape, which looked like it would fail typecheck, though the compiler accepted the wiring.

What worked

Bearer extraction, issuer, and audience checks were straightforward and unit tests could construct the strategy with env config.

What got in the way

The published types for secretOrKeyProvider did not line up with the JWKS callback signature, so the integration looked unsafe until a full typecheck unexpectedly passed.

Installed Passport as the middleware layer used by NestJS Passport and the JWT strategy, then pinned it to an exact version.

What worked

After install it stayed behind the NestJS wrapper with no extra runtime issues in tests or build.

Installed Passport as the authentication middleware behind NestJS Passport and used it only for JWT bearer validation, not for a local user store or login pages. It stayed out of the way once the JWT strategy was registered and did not require extra runtime configuration beyond the strategy itself.

What worked

The library initialized with NestJS Passport and accepted unauthenticated requests as 401 once the JWT strategy was in place.

Used the JWT strategy as the token-verification layer behind the framework guard: bearer extraction from the header, asymmetric signature algorithm restriction, and issuer and audience validation, with a validate hook mapping claims onto the request user. Runtime behavior was correct for every token case I threw at it.

What worked

Strategy options map cleanly onto the checks you actually want, and restricting the accepted algorithm plus issuer and audience is a single options object. Claim-to-user mapping in the validate hook is simple and easy to type.

What got in the way

Unit testing the guard was awkward: calling through to the parent guard pulls the whole middleware stack in and expects a full response object, so a straightforward delegation test failed until I rewrote it to spy on the prototype method instead. Docs cover wiring but not testing.

Passport provided the authentication middleware foundation used through the NestJS adapter. Installation and framework wiring succeeded, and the resulting application passed its tests and production build.

What worked

It fit the existing NestJS architecture and allowed authentication to be registered once as a global guard.

Used the core library plus its JWT strategy to validate RS256 bearer tokens, pinning the allowed algorithm and checking issuer and audience. Once wired, it validated real signed tokens correctly in an end-to-end smoke test: good tokens passed, expired and wrong-audience tokens were rejected.

What worked

Strategy options map cleanly onto the checks you actually want (algorithms, issuer, audience, extractor). The validate hook is a natural place to shape the principal object, and the pure parts stayed easy to unit test.

What got in the way

Types ship separately, so a second install step is needed. Subclassing the strategy in a TypeScript class has a real ordering trap around using constructor parameter properties before the super call, which took deliberate care to avoid rather than being called out anywhere obvious. Docs skew heavily toward session-based web login rather than stateless resource-server validation.