OAuth 2.0 (Protocol / RFC 6749)
OAuth 2.0 is a delegated authorization protocol (RFC 6749/6750) that allows agents to obtain short-lived access tokens via grant types (Authorization Code + PKCE, Client Credentials, Device Flow) to access protected resources on behalf of a user or service.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
RFC 6749 mandates TLS for all token endpoints. PKCE (RFC 7636) and DPoP (RFC 9449) extensions significantly harden security. The 'none' algorithm and implicit flow are deprecated in OAuth 2.1 BCP.
⚡ Reliability
Best When
An agent needs to call APIs on behalf of users or services using industry-standard delegated authorization with scoped, short-lived tokens.
Avoid When
You need a full identity management system, session management, or user registration — OAuth 2.0 alone does not provide those.
Use Cases
- • Obtain a client_credentials access token to call third-party APIs on behalf of a service (machine-to-machine agent workflows)
- • Implement Authorization Code + PKCE flow to act on behalf of a human user without storing their credentials
- • Use Device Authorization Flow to authenticate an agent running in a headless or CLI environment
- • Refresh expired access tokens automatically using a refresh_token to maintain long-running agent sessions
- • Validate incoming Bearer tokens at an API gateway before routing requests to downstream agent tools
Not For
- • User authentication identity (OAuth 2.0 is authorization only; use OIDC or a dedicated IdP for identity)
- • Storing user passwords or managing credentials directly (it is a delegation protocol, not an identity store)
- • Fine-grained resource permissions within an application (use a dedicated authz layer like OpenFGA on top)
Interface
Authentication
This is the protocol itself. Individual authorization servers (Hydra, Okta, Auth0, etc.) implement the spec and define their own credential requirements.
Pricing
RFC 6749/6750 are open IETF standards. Costs arise from choosing a managed OAuth server (Auth0, Okta, Logto Cloud, Ory Network).
Agent Metadata
Known Gotchas
- ⚠ Refresh token rotation: if a network error occurs mid-rotation, the old refresh token may be invalidated before the agent stores the new one — always persist the new token atomically before using it
- ⚠ Clock skew: the 'exp' claim in access tokens uses absolute Unix timestamps; if the agent host clock drifts, tokens may appear expired or valid when they are not — build in a 60-second skew buffer
- ⚠ PKCE code_verifier must be generated per-authorization request and stored server-side; agents that reuse or cache verifiers break the PKCE security guarantee
- ⚠ state parameter is required for CSRF protection in Authorization Code flow; agents that skip it or use a static value are vulnerable to authorization code injection
- ⚠ Client Credentials grant issues non-refreshable tokens — agents in long-running loops must proactively re-authenticate before expiry rather than waiting for a 401
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for OAuth 2.0 (Protocol / RFC 6749).
Scores are editorial opinions as of 2026-03-06.