11 Authorization for APIs

APIs are the connective tissue of modern systems, but that makes them a major security boundary: they must be open enough to support communication while still preventing misuse. The chapter frames API authorization as two related problems: protecting internal service-to-service traffic and supporting external delegation to third-party applications. In both cases, the core challenge is to ensure that each request is checked against policy in a way that is consistent, fine-grained, and hard to bypass.

For internal microservices, ACME’s move away from a monolith exposed many new request paths, and authorization logic that was once centralized became fragmented across services. To fix this, the chapter compares three enforcement patterns: using the API gateway for edge traffic, using a service mesh with sidecar proxies for east-west traffic, and using per-service proxies for legacy or transitional APIs. These patterns differ operationally, but all of them normalize requests into a common decision format and send them to Cedar, which becomes the policy decision point. The examples emphasize avoiding confused deputy problems by making decisions based on the true principal, resource, action, and context rather than simply trusting the calling service.

For external access, OAuth solves the password anti-pattern by letting users or organizations grant limited, revocable access to applications through scopes and tokens. The chapter contrasts the Authorization Code Grant, used when a person like Kate explicitly consents to a tool such as BI Explorer, with the Client Credentials Grant, used for headless integrations like CustCo’s Task App. OAuth provides the delegation boundary, but Cedar still makes the final authorization decision for each request, allowing ACME to combine broad delegation with precise business rules. The overall message is that API security works best when delegation and policy enforcement are layered together, giving both flexibility for integration and strict control over sensitive data.

API Gateway as a centralized enforcement point. Carol’s request moves through the Manager Dashboard to the HR API. The API Gateway functions as the PEP, forwarding a normalized PARC request to the Cedar engine (PDP). The HR API receives the call only if Cedar returns an allow decision.

Service mesh enforcement with sidecars. Cedar evaluates each document sent from Docs to Search. Documents tagged "Legal" are denied; others are allowed.

Per-service proxy enforcement. The Finance API is not yet part of the service mesh, so ACME places a proxy directly in front of it. The proxy validates caller identity, constructs a Cedar authorization request, and forwards the call only if Cedar allows it.

OAuth roles in action. Kate is the resource owner, BI Explorer is the client, ACME’s Customer Authentication Service is the authorization server, and the Customer Collaboration API is the resource server.

Authorization Code Grant. The resource owner’s browser handles login and consent. ACME’s authorization server provides a short-lived code, which the client then exchanges for an access token over a secure back channel.

 OAuth consent screen for BI Explorer. Kate reviews the scopes requested by BI Explorer. She grants permission to read workspace membership and view document metadata (but not content), and she does not allow BI Explorer to subscribe to updates. The token issued to BI Explorer will be limited to the scopes Kate selected.

 CustCo’s Task App authenticates to ACME’s authorization server using its client credentials and receives an access token that represents the app (an integration principal). Admin setup and the installation record bind the app to CustCo and specific workspaces.

Using an OAuth token with Cedar. The client (BI Explorer or Task App) includes an access token in its API request. The API gateway validates the token and then creates a PARC request for Cedar. The request proceeds to the Customer Collaboration API and returns data only if Cedar grants permission.

• ACME secures APIs on two fronts: Cedar policies safeguard internal micro­services at gateways, meshes, and proxies, while OAuth tokens, combined with Cedar, allow safe external delegation to customer applications.
• API authorization works best when each request path has a clear enforcement point that can validate identity, gather context, invoke policy, enforce the decision, and log the result.
• ACME enforces internal policies using gateway, service mesh, and per-service proxy patterns, with Cedar serving as the decision engine.
• OAuth enables delegated access without sharing passwords, with scopes specifying which APIs a token bearer can access.
• The Authorization Code Grant (Kate’s BI Explorer) and Client Credentials Grant (CustCo’s Task App) demonstrate the two most important methods for obtaining tokens.
• Regardless of grant type, tokens are validated at the gateway and then converted into PARC requests for Cedar, which enforces detailed access control.

FAQ