The authorization code flow is an OAuth grant for delegated API access. A person authorizes a client application to access data within selected scopes, receives no need to share a password with that client, and the client exchanges a short-lived authorization code for an access token through a secure back channel. section 11.2.3 section 11.4
It separates a user-facing decision from API enforcement. The browser handles sign-in and consent; the authorization server issues the code; and the client obtains a token. The approved scopes limit the token’s API access, while finer-grained authorization can still decide whether a particular request is allowed. section 11.2.3 section 11.2.4
A typical flow proceeds as follows:
- The client starts a connection and redirects the user to the authorization server with requested scopes. section 11.2.3
- The authorization server authenticates the user and displays the requested permissions for review. section 11.2.3
- After approval, the authorization server provides a short-lived authorization code. section 11.2.3
- The client exchanges the code with the authorization server for an access token over a secure back channel. section 11.2.3
- The client sends the token with an API request; the gateway validates its signature, issuer, audience, expiration, and scopes before policy evaluation. section 11.2.4
Figure 11.5 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.
The diagram distinguishes the browser-mediated login and consent step from the client’s secure back-channel exchange of the short-lived code for an access token. section 11.2.3
BI Explorer receives delegated access
Kate connects BI Explorer to a collaboration platform to create dashboards. BI Explorer requests workspace-read, document-metadata-read, and event-subscription scopes. Kate may approve metadata and workspace access while declining event subscriptions or document content access. The resulting token represents Kate’s delegated approval and is limited to the scopes she selected. On a metadata request, the gateway validates that token, builds a principal-action-resource-context (PARC) request, and Cedar decides whether Kate may read metadata for the workspace. section 11.2.3 section 11.2.4
This flow addresses external delegation; it is distinct from the Client Credentials Grant, where a server-to-server application obtains a token directly without a person’s interaction. In either case, a token establishes identity and scope at the API boundary, but Cedar policies can enforce detailed rules using the principal, action, resource, and request context. section 11.2.3 section 11.2.4







