Skip to content

CONCEPT Cited by 2 sources

Zero-trust authorization

What it is

Zero-trust authorization is the design principle that every tier that handles a privileged request must independently verify authorization — no tier is trusted to pre-authorize on behalf of downstream tiers. A compromised or buggy API gateway, backend service, or middleware cannot leak access, because the next tier will re-verify.

Contrast with perimeter-trust architectures: verification happens at the ingress boundary, everything behind it is implicitly trusted. One compromised boundary → full access.

Why it matters

Three forces drive zero-trust:

  • Layered failure modes. Authentication bugs, authorization bugs, tenant-routing bugs, and data-access bugs each have different failure surfaces. Verifying at every layer means a bug in one doesn't compose into full compromise.
  • Multi-tenant SaaS. Cross-tenant leakage is catastrophic. Re-verifying tenant_id at the data layer is the last line of defense if upstream routing misconfigures.
  • Microservice fanout. As request paths lengthen (ingress → service A → service B → database), trusting upstream decays exponentially. Zero-trust pushes verification to each boundary.

Production shape (Convera)

Convera's multi-tenant mode:

Authorizer (API Gateway tier)    — AVP check #1
         ↓ (tenant_id in header)
Backend Kubernetes pod           — AVP check #2 (re-verify tenant_id)
         ↓ (with tenant context)
RDS                              — accepts only tenant-scoped requests

The backend re-validates with Verified Permissions, not just trusts the tenant_id header from API Gateway. The post names this explicitly as "zero-trust policy." (Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

Cost

Zero-trust doubles (or more) the authorization work per request: each layer pays for verification. Mitigations:

  • Decision caching at each layer.
  • Stateless verification, so verifiers scale independently.
  • Scope narrowing at each tier — the inner-tier check doesn't repeat the outer-tier work, it verifies the additional-trust increment (e.g., "this request is really for this tenant").

Relation to "zero-trust network access"

Zero-trust authorization and zero-trust network access are siblings:

  • Zero-trust network access: every network connection authenticates + authorizes, no implicit trust from IP / VPN / LAN membership.
  • Zero-trust authorization: every authorization decision is made independently at every tier that enforces a boundary.

Both share the philosophical core: "never trust, always verify." They stack — zero-trust network carries authenticated identity to every tier; zero-trust authorization uses it at every tier.

Caveats

  • Perfect zero-trust is expensive and often unnecessary. Pragmatic zero-trust picks the boundaries that matter: ingress, tenant boundary, data-layer boundary. Re-verifying on every in-process function call is overkill.
  • Redundant policies must stay in sync. If the API-Gateway authorizer and the backend verifier evaluate different policy stores, a drift bug can manifest as "works through the API, blocked at the backend" incidents.

Seen in

Last updated · 542 distilled / 1,571 read