The Nest `@Controller('.well-known/jwks.json')` declared in PR #138
combined with `setGlobalPrefix('api', { exclude: [...] })` landed
the JWKS route at neither `/.well-known/jwks.json` (intended) nor
`/api/.well-known/jwks.json` (with-prefix fallback). Both URLs
404'd. Nest 11 routes via path-to-regexp v8, whose grammar broke
backward compatibility on several leading-character cases — the
combination of a leading-dot path segment + the `exclude` rewrite
falls into one of them.
Fix
Sidestep Nest's router for this one route. The JWKS payload-builder
stays in the DI graph (`JwksPublisher`, formerly `JwksController`,
minus the Nest decorators), and `main.ts` resolves it from the
container then registers a plain Express GET handler at
`/.well-known/jwks.json`. Express's router accepts the leading dot
verbatim and the route lands exactly where RFC 8615 says it should.
Touched
- jwks.controller.{ts,spec.ts} → jwks.publisher.{ts,spec.ts}.
Same constructor, same `jwks()` method shape — only the
@Controller / @Get decorators are gone. The DI signature is
unchanged so the existing tests rename → green without other
edits.
- downstream.module.ts: drops the `controllers` array, lists
`JwksPublisher` as a provider + export so `main.ts` can resolve
it.
- main.ts: drops the `setGlobalPrefix` exclude option, drops the
`RequestMethod` import, registers an Express GET handler at the
bare-root JWKS path immediately before `app.listen()`.
Verified locally: `curl http://localhost:3000/.well-known/jwks.json`
returns the expected JWKS shape (`kty=RSA`, `kid=bff-2026-05`,
`alg=RS256`, `use=sig`).
Tests: still 358 specs passing. No new specs added — the routing
fix is a wiring change tested manually with the real BFF; the
publisher's `jwks()` method is unchanged so the rename-only spec
delta keeps the existing coverage.
Julien Gautier
98446a9f35