Choosing the Right OAuth 2.0 Flow

From PiRho Knowledgebase
Revision as of 05:36, 20 April 2026 by Dex (talk | contribs) (Created page with "= Choosing the Right OAuth 2.0 Flow = == A Capability-Driven Approach == '''Summary:''' OAuth 2.0 defines multiple authorization flows, each designed for a specific combination of identity type, risk profile, and operational context. Problems arise when these flows are treated as interchangeable or selected based purely on convenience. This article reframes OAuth flow selection as a capability- and channel-driven architectural decision. ---- == Context == OAuth 2.0...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Choosing the Right OAuth 2.0 Flow

A Capability-Driven Approach

Summary: OAuth 2.0 defines multiple authorization flows, each designed for a specific combination of identity type, risk profile, and operational context. Problems arise when these flows are treated as interchangeable or selected based purely on convenience. This article reframes OAuth flow selection as a capability- and channel-driven architectural decision.

Context

OAuth 2.0 is often introduced by answering a narrow question:

“How do we get an access token?”

The more important question is:

“What kind of identity is making this request, and under what conditions?”

OAuth flows encode assumptions about:

  • Human vs machine identity
  • Interactive vs non-interactive use
  • Token exposure risk
  • Credential handling capability

Choosing the wrong flow weakens a system even when every token is technically valid.

OAuth Flows Are Not Variants

A common misconception is that OAuth flows are simply different ways to reach the same outcome. In reality, each flow represents a distinct capability boundary.

Choosing a flow implicitly answers:

  • Who is authenticating?
  • Is a human present?
  • Can secrets be stored securely?
  • Can the user be redirected?
  • Is long-lived access acceptable?

Once issued, tokens inherit these assumptions.

Core OAuth Flows (Modern Reality)

Authorization Code Flow

Best suited for

  • Server-side web applications
  • Confidential clients

Characteristics

  • User authenticates interactively
  • Authorization code exchanged server-side
  • Tokens never exposed to the browser
  • Supports refresh tokens

This flow maps cleanly to interactive user channels.

Authorization Code Flow with PKCE

Best suited for

  • Single-page applications (SPAs)
  • Mobile applications
  • Desktop applications

What PKCE adds

  • Cryptographic proof binding
  • Protection against code interception
  • No reliance on a client secret

This is the modern default for public clients and replaces the Implicit Flow.

Client Credentials Flow

Best suited for

  • Service-to-service communication
  • Background jobs
  • Automation

Characteristics

  • No user context
  • Client authenticates directly
  • Tokens represent a service identity

Tokens issued via this flow must never authenticate user interfaces.

Device Authorization Flow

Best suited for

  • CLI tools
  • Smart TVs
  • IoT and constrained devices

This flow enables human authentication without requiring a browser on the device itself.

Deprecated and Transitional Flows

Resource Owner Password Credentials

This flow exists only for legacy systems.

Risks

  • Client handles user passwords
  • MFA is bypassed
  • Zero-trust boundaries collapse

If present, it must be tightly restricted and clearly marked as transitional.

Implicit Flow

The Implicit Flow is deprecated.

Why

  • Tokens exposed in URLs and logs
  • No refresh tokens
  • No effective mitigations

There is no modern justification for using it.

Flow Selection by Authentication Channel

Rather than choosing flows per application, choose them per authentication channel.

Interactive User Channel

Allowed

  • Authorization Code
  • Authorization Code with PKCE

Disallowed

  • Client Credentials
  • Password Grant

First-Party API Client

Allowed

  • Client Credentials
  • Authorization Code (on behalf of user)

Controls

  • Strict audience enforcement
  • Static scope allow-lists

Third-Party API Client

Allowed

  • Authorization Code with PKCE
  • Client Credentials (approval-based)

Disallowed

  • Broad refresh tokens
  • Wildcard scopes

Scopes here should be treated like firewall rules.

Machine / Background Service

Allowed

  • Client Credentials only

Disallowed

  • Any user-involved flows
  • Refresh tokens

These tokens must never authenticate human surfaces.

Legacy / Transitional Channel

Allowed

  • Explicitly whitelisted flows only

Required safeguards

  • Reduced scope ceilings
  • Short token lifetimes
  • No refresh tokens
  • Clear deprecation plan

Common Failure Patterns

  • Using interactive flows for automation
  • Accepting machine tokens on admin UIs
  • Enabling password grants indefinitely
  • Treating flows as client configuration rather than policy

These are flow-selection failures, not cryptographic ones.

Conclusion

OAuth 2.0 flows encode trust assumptions, identity models, and risk tolerance.

Choose flows based on:

  • Who is authenticating
  • How interactive the channel is
  • Where tokens will travel
  • What assurance level is required

When flows are selected deliberately, OAuth becomes a system of bounded capabilities rather than a loose token-minting service.

Retrieved from "https://knowledgebase.pirho.net/index.php?title=Choosing_the_Right_OAuth_2.0_Flow&oldid=397"