OAuth 2.0 is a delegation protocol for letting an application call protected APIs on a person’s or organization’s behalf without receiving their password. Instead of handing a photo-printing site or reporting tool full account credentials, the resource owner approves limited scopes, such as reading document metadata but not sending email. Access is revocable without changing the account password. section 11.2
OAuth separates four roles. The resource owner owns the data; the client requests access; the authorization server authenticates the owner and issues a token after consent; and the resource server hosts the protected API. The client presents the resulting access token to the resource server rather than impersonating the owner with a password. section 11.2.1
Figure 11.4 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.
Use the role diagram to trace a delegated request from a resource owner through a client and authorization server to a protected API. section 11.2.1
OAuth scopes create an outer boundary for API access, but they are not the entire authorization decision:
- Scopes state the kinds of API access a token bearer was approved to request, such as workspace reading, document-metadata reading, or event subscription. section 11.2 section 11.2.4
- A gateway validates the bearer token, derives a principal, action, resource, and context from the request, and sends that request to Cedar for policy evaluation. section 11.2.4
- Cedar can further restrict access by membership, tenant ownership, allowed workspaces, sensitivity, or required user attribution; a denied decision blocks the API call. section 11.2.4 section 11.3
Two token-acquisition patterns serve different callers. The Authorization Code Grant supports a person approving a third-party client’s access. The Client Credentials Grant supports an integration authenticating itself for background work. In either case, token validation and runtime policy evaluation remain separate steps: OAuth identifies the delegated boundary, while Cedar decides whether the requested action on the specific resource is allowed. section 11.2.4 section 11.4
Reporting tool with limited workspace access
Kate connects BI Explorer to a collaboration platform and approves workspace and document-metadata scopes through the Authorization Code Grant. BI Explorer sends its bearer token when requesting documents from the custco-sales workspace. The gateway validates the token and Cedar permits the request only if Kate belongs to that workspace; a request for a workspace she does not belong to is denied. section 11.2.1 section 11.2.4
Figure 11.8 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.
Follow the enforcement path: a client sends a token, the gateway validates it and creates a Cedar request, and the API receives only allowed requests. section 11.2.4
This layering supports consistent API authorization across external integrations and internal service paths. OAuth avoids broad, fragile credential sharing, while a centralized policy decision can apply the same detailed rules regardless of whether the caller is a person, service, or external application. Clear enforcement points should validate identity, gather context, evaluate policy, enforce the result, and log it. section 11.3 section 11.4
