Skip to main content

ADR-0001: M2M Auth Strategy for CMP Registry

  • Status: Accepted
  • Date: 2026-01-09
  • Author: @digiwedge/engineering
  • Supersedes: None

Last updated: 2026-01-09

Context​

The CMP Registry receives machine-to-machine (M2M) requests for POST /consent/v1/append from external systems (e.g., customer sites or backend services). This is a different trust boundary from browser-based apps that use the IDP session model. The registry must verify bearer tokens cryptographically, but there is no second consumer yet that justifies a shared M2M auth library.

Decision​

  • Keep the CMP Registry JWT guard local to apps/cmp/registry for now.
  • Require issuer/audience validation and cryptographic verification via:
    • HS256 shared secret (OIDC_HS_SECRET) when configured, with JWKS fallback.
    • JWKS discovery or explicit OIDC_JWKS_URI.
  • Require an exp claim and return 401 for invalid or missing tokens when APPEND_AUTH_REQUIRED=1 is enabled.
  • Revisit extraction to a shared @digiwedge/m2m-auth package if another service needs M2M JWT verification.

Consequences​

  • CMP Registry has a clear, documented M2M auth contract and env configuration.
  • Security posture improves without introducing premature shared abstractions.
  • If a second service adopts M2M JWT auth, extraction work is well-scoped and can standardize envs (OIDC_ISSUER, OIDC_AUDIENCE, OIDC_JWKS_URI, OIDC_HS_SECRET).

Follow-ups​

  1. Reassess shared library extraction when a second M2M consumer ships.
  2. Keep CMP docs and operator checklist aligned with the required envs.