CONCEPT Cited by 1 source

Authorization as a service

Definition

Authorization as a service is authorization delivered as a platform capability: application teams opt in with a single declarative statement (e.g., "protect application X") and the platform transparently handles the policy engine, bundle distribution, observability, and monitoring. The application's responsibility ends at the policies themselves — everything else belongs to the platform.

Contrast with the common anti-shape: "every team deploys its own OPA sidecar, wires its own metrics, maintains its own bundle fetch, and re-implements its own runbooks." That is OPA-as-a-library, not authorization-as-a-service.

Load-bearing properties

• Single opt-in surface. Enabling authorization for an application is one annotation / one config line / one API call, not an onboarding doc.
• No infrastructure responsibility inherited. App teams do not pick storage, do not configure telemetry, do not pick the engine version, do not tune timeouts.
• Policy is app-team-owned, engine is platform-team-owned. The concepts/platform-team-vs-application-team-split: platform engineers own how authorization runs; app teams own what the rules say. See Rego bundles as the handoff artifact.
• The engine runs where enforcement happens. Typically the ingress / edge / service mesh proxy; see patterns/ingress-layer-authorization-offload and patterns/embedded-opa-in-proxy.
• Control-plane failure does not stop enforcement. See concepts/control-plane-data-plane-separation and patterns/s3-as-policy-bundle-source-for-availability.

Seen in

• sources/2024-12-05-zalando-open-policy-agent-in-skipper-ingress — Zalando's canonical instance. Platform team embeds OPA as a library inside Skipper ingress, hides bundle source (S3) + observability (Lightstep) + bootstrap rules behind the platform; app teams opt in with a one-line Skipper filter annotation opaAuthorizeRequest("my-application") and write Rego in their own Git repos. Explicitly framed in the post: "Enabling OPA for a specific application is as easy as just stating 'application X should be protected' without touching multiple YAML files, adding monitoring, and inheriting many more responsibilities to be compliant."

Related

• concepts/embedded-opa-library-in-proxy — the runtime mechanism enabling this at ingress scale
• concepts/virtual-opa-instance-per-application — the multi- tenancy model inside one proxy process
• concepts/externalised-authorization — policies outside code
• concepts/platform-team-vs-application-team-split — the ownership axis this pattern operationalises
• patterns/ingress-layer-authorization-offload — the deployment topology
• patterns/embedded-opa-in-proxy — the implementation pattern