Dex: 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..."

2026-04-20T05:36:09Z

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..."

New page

= 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.

Choosing the Right OAuth 2.0 Flow - Revision history