0013 — JWT authorization at the service

Decided. Supersedes the authentication placement in Architecture: JWT validation and actor header stamping at the edge.

A JWT is not authentication. It is a signed authorization credential: authn asserts that the bearer may act as principal sub until exp. Authorization happens at the service when it is called — the service must validate that credential before doing anything else.

Trust chain

Authentication (proving identity with credentials) happens upstream — OIDC login with the IdP, handled by authn. That ceremony produces a short-lived JWT signed by authn.

When a service receives a call:

1. Validate the credential — Authorization: Bearer …: verify signature against authn JWKS, check exp, iss, aud. This is the trust chain: the service trusts only tokens signed by a key it can verify. No valid JWT → 401, Cedar never runs.
2. Evaluate policy — Cedar against the verified sub (actor FID) and local principals copy. Deny → 403.

The edge forwards the Authorization header. It does not validate JWTs or stamp identity headers. Trust is cryptographic at the service, not positional at the edge.

Alternatives

• Edge validates JWT and stamps actor_fid. Services trust the header. No signature check at the service — policy evaluation on an unverified label.
• Central authorization service per request. Network hop on every call.

Consequences

• JWT validation middleware is required in every service, before Cedar.
• X-Dev-Actor / DevAuth are temporary local-only stand-ins without a trust chain; they are not authorization.
• JWKS URL and expected iss / aud are service configuration, sourced from authn.
• 0007 still holds for Cedar evaluation in process.