Skip to content

ADR-0001. Single JWKS issuer as the platform trust root

FieldValue
StatusAccepted
Date2026-01-08
Decidersidentity-team, platform-architect
Supersedes

Context

  • BANA has 10+ backend services that all need to authenticate users.
  • Each service needs to verify JWTs without phoning home on every request.
  • Two patterns:
    1. Shared HMAC secret — every service has the same secret; symmetric.
    2. Asymmetric (JWKS) — one issuer signs, others verify with public keys.

Decision

@nx/identity is the only signing authority. It uses ES256 (ECDSA over P-256) and exposes public keys at GET /jw-certs (RFC 7517 JWKS format). All other services extend VerifierApplication from @nx/core which fetches /jw-certs at boot, caches by kid, and verifies signatures locally.

There is no secondary issuer, federation, or per-merchant key isolation today.

Consequences

ProsCons
Sister services don't need a shared secretSingle point of trust — if signing key leaks, every JWT is forgeable
Asymmetric: leaks of public key are irrelevantKey rotation is operationally tricky (need kid-aware sister cache)
Standard format (JWKS / JWS / JWT) — interoperableSingle key for all merchants — no tenant isolation
Sister services have no auth dependency on identity per-requestIdentity is a platform-wide critical path (alert priority HIGH)

Alternatives Considered

OptionProsConsWhy rejected
Shared HMAC secretSimpleAny leaked secret compromises everything; rotation requires coordinated restartOperational fragility
Per-merchant signing keyTenant isolationMassive complexity in sister verification logic; key explosionPremature; multi-tenant key isolation in scope-excluded
Per-service signingDecentralizedCross-service trust collapses; every service needs to know every other's keysNope
External IdP (Auth0, Cognito)OutsourcedVendor lock-in; latency; costWe need internal control of role/permission semantics

References

  • @nx/core IssuerApplication and VerifierApplication base classes
  • JWKSIssuerTokenService (used by AuthenticationService.generateToken)
  • RFC 7517 (JWKS), RFC 7519 (JWT), RFC 7515 (JWS)

Proprietary and Confidential. Unauthorized copying, distribution, or use of this software is strictly prohibited.