liveBook · Manning

Authorization code flow

As explained in Authorization in Action

The authorization code grant is an OAuth flow in which a client obtains a short-lived authorization code after user authorization and exchanges it for an access token.

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

How Authorization in Action covers it

How deep it goes
Explains consent, code exchange, token validation, and subsequent Cedar policy evaluation rather than protocol internals.
Examples
Uses Kate connecting BI Explorer for workspace and document-metadata access with selectively approved scopes.
What you can do after
Apply it via OAuth to grant a client scoped delegated access, then enforce requests through gateway validation and Cedar.
How it connects
Connects OAuth, access tokens, scopes, API gateways, Cedar, and the Client Credentials Grant.

Also explained in

Compare how 8 books explain authorization code flow →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.