OAuth 2.0 and OpenID Connect in Identity Security

OAuth 2.0 and OpenID Connect (OIDC) form the dominant authorization and authentication delegation framework across modern enterprise, cloud, and consumer-facing identity systems. These protocols define how applications request access to protected resources and verify user identity without exposing raw credentials — a distinction with direct implications for identity and access management architecture, regulatory compliance, and attack surface management. This page covers the structural mechanics of both protocols, their classification boundaries, the regulatory context in which they operate, and the contested tradeoffs practitioners face when deploying them at scale. The Identity Security Providers resource provides supplementary context on the broader service landscape within which these protocols operate.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps (Non-Advisory)
• Reference Table or Matrix
• References

Definition and Scope

OAuth 2.0 is an authorization framework, not an authentication protocol. Published by the Internet Engineering Task Force (IETF) as RFC 6749 in 2012, it defines a delegation mechanism by which a resource owner grants a third-party client application limited access to a protected resource hosted on a resource server — without sharing the owner's credentials with the client. The scope is bounded: OAuth 2.0 addresses what an application is permitted to do, not who is performing the action.

OpenID Connect (OIDC) fills that gap. Maintained by the OpenID Foundation, OIDC is an identity layer built on top of the OAuth 2.0 authorization framework. It adds a standardized identity token — the ID token, formatted as a JSON Web Token (JWT) — that carries verified claims about the authenticated user, including a subject identifier (sub), issuer (iss), and audience (aud). OIDC 1.0 was finalized by the OpenID Foundation in February 2014.

Together, OAuth 2.0 and OIDC serve three distinct operational functions: delegated authorization (OAuth 2.0), federated authentication (OIDC), and API access control (OAuth 2.0 bearer tokens). Their combined scope now extends across single sign-on (SSO) deployments, mobile application authentication, machine-to-machine API authorization, and cross-organizational identity federation. In the context of US federal systems, NIST Special Publication 800-63C governs federation assurance levels (FAL1 through FAL3) and treats OIDC and SAML as the two primary assertion mechanisms for federal agency federation.

The distinction between authorization and authentication is not semantic — it defines the attack surface. Misapplying OAuth 2.0 as an authentication mechanism (without the OIDC identity layer) has been the source of documented security vulnerabilities, including token substitution and confused deputy attacks catalogued in the OAuth Security Best Current Practice (IETF RFC 9700, published 2025).

Core Mechanics or Structure

The OAuth 2.0 framework defines 4 canonical roles: the Resource Owner (typically the end user), the Client (the application requesting access), the Authorization Server (the server issuing tokens), and the Resource Server (the API or service hosting protected resources).

Access is granted through a structured flow called a grant type. RFC 6749 originally defined 4 grant types:

1. Authorization Code — The client redirects the user to the authorization server, receives a short-lived authorization code via redirect, and exchanges it for an access token via a back-channel server-to-server call. This is the most secure flow for confidential clients.
2. Implicit — The access token is returned directly in the redirect URI fragment. Deprecated by OAuth 2.0 Security Best Current Practice (BCP) due to token leakage risk via browser history and referrer headers.
3. Resource Owner Password Credentials (ROPC) — The client collects the user's credentials directly. Also deprecated in the Security BCP for all but legacy migration scenarios.
4. Client Credentials — Used for machine-to-machine flows where no end user is involved. The client authenticates directly to the authorization server using its own credentials.

Proof Key for Code Exchange (PKCE), defined in RFC 7636, was introduced to protect the Authorization Code flow against authorization code interception attacks, particularly in public clients (mobile apps, SPAs). OAuth 2.1, the consolidating draft in active IETF review, mandates PKCE for all Authorization Code grant uses.

For OIDC, the core exchange produces 3 token types:
- ID Token — A JWT asserting the user's authenticated identity to the client.
- Access Token — An opaque or structured credential authorizing the client to call protected APIs.
- Refresh Token — A long-lived credential used to obtain new access tokens without re-authenticating the user.

The OIDC UserInfo Endpoint provides a standardized API that clients call (using the access token) to retrieve additional identity claims beyond those encoded in the ID token. Claim scopes — openid, profile, email, address, phone — are defined in the OpenID Connect Core 1.0 specification.

Causal Relationships or Drivers

The adoption of OAuth 2.0 and OIDC at enterprise scale is traceable to 4 converging pressures:

API proliferation: The shift from monolithic enterprise software to microservice architectures created a need for fine-grained, machine-readable authorization that session cookies could not satisfy. OAuth 2.0 bearer tokens became the standard API authorization mechanism across cloud platforms including AWS, Google Cloud, and Microsoft Azure.

Regulatory requirements for federated identity: Federal mandates under NIST SP 800-63-3 require agencies to support federated identity at defined assurance levels. The NYDFS Cybersecurity Regulation (23 NYCRR 500) and HIPAA Security Rule (45 CFR §164.312) impose access control requirements that OIDC-based SSO directly addresses through centralized authentication and auditable token issuance.

Credential exposure reduction: Password sharing between applications — the pre-OAuth pattern — concentrates credential risk. Delegation via OAuth 2.0 scoped access tokens limits the blast radius of a compromised application to the specific scopes granted, rather than full account access.

Mobile and consumer identity scale: Native mobile applications require authentication flows that function without server-side session state. OIDC's support for the Authorization Code + PKCE flow — outlined in the OAuth 2.0 for Native Apps (RFC 8252) best current practice — provides a secure, platform-independent mechanism for authenticating users in mobile contexts.

Classification Boundaries

OAuth 2.0 and OIDC occupy a specific position in the identity protocol landscape. Understanding where their boundaries fall prevents misapplication:

OAuth 2.0 vs. OIDC: OAuth 2.0 governs authorization only. OIDC is a superset that adds authentication semantics. A deployment using only OAuth 2.0 (no OIDC layer) cannot assert who the user is — it can only assert that the user authorized a specific access scope.

OIDC vs. SAML 2.0: Both support federated authentication and SSO. SAML 2.0, governed by OASIS, uses XML-based assertions and is dominant in enterprise and government contexts with legacy infrastructure. OIDC uses JSON/JWT and is dominant in cloud-native and mobile-first architectures. The resource contextualizes how these protocol categories are organized for practitioners navigating service selection.

OAuth 2.0 vs. API Keys: API keys are static shared secrets with no expiration mechanism defined at the protocol level. OAuth 2.0 access tokens carry defined expiration (exp claim), issuer binding, and audience binding — structural security properties API keys lack.

OIDC vs. Kerberos: Kerberos (MIT-developed, embedded in Microsoft Active Provider Network) operates within closed network boundaries using ticket-granting tickets (TGTs). OIDC is designed for open, internet-scale federation across organizational and network boundaries. The two are not interchangeable and address different trust perimeter assumptions.

Tradeoffs and Tensions

Token format flexibility vs. interoperability: Authorization servers may issue opaque access tokens (random strings requiring introspection) or structured JWTs (self-contained, verifiable without server round-trips). JWTs reduce latency and server load but cannot be revoked before expiration — a meaningful tension in high-security environments. RFC 7009 (OAuth 2.0 Token Revocation) and RFC 7662 (Token Introspection) provide mechanisms to address revocation, but they reintroduce the server dependency that JWTs were chosen to eliminate.

Scope granularity vs. administrative complexity: Fine-grained scopes reduce over-privilege but exponentially increase the administrative surface for scope management, consent UI design, and client registration. Coarse scopes simplify administration but violate least-privilege principles mandated under frameworks including NIST SP 800-53 Rev 5 (AC-6: Least Privilege).

Short-lived tokens vs. user experience: The security recommendation from RFC 9700 favors short-lived access tokens (minutes, not hours) to limit the damage from token leakage. Short lifetimes require frequent refresh token use, which increases authorization server load and can degrade user experience in high-frequency API environments.

Public client security vs. feature support: Mobile and single-page applications are classified as public clients because they cannot securely store client secrets. PKCE mitigates code interception, but public clients cannot use client authentication mechanisms (mutual TLS, private key JWT) that provide stronger authorization server binding for confidential clients.

Centralized IdP dependency vs. resilience: OIDC federation centralizes authentication at the Identity Provider. This simplifies governance but introduces a single point of failure — an IdP outage affects all federated relying parties simultaneously. Distributed session state and fallback authentication paths are architectural choices that add complexity.

Common Misconceptions

Misconception: OAuth 2.0 authenticates users.
OAuth 2.0 does not authenticate users. It authorizes access on behalf of a resource owner. The presence of an access token confirms that authorization occurred — it does not confirm user identity. OIDC's ID token is the authentication artifact; an access token alone cannot be used for this purpose, as clarified in the OpenID Connect Core 1.0 specification.

Misconception: The Implicit grant is acceptable for SPAs.
The Implicit grant was historically recommended for browser-based applications. The OAuth 2.0 Security BCP (RFC 9700) explicitly deprecates the Implicit grant and mandates Authorization Code + PKCE for all public clients, including SPAs. Authorization servers that still offer Implicit grant as a primary option for SPAs are operating against current IETF guidance.

Misconception: JWTs are encrypted by default.
JWTs are signed (JWS) by default — they verify integrity and issuer authenticity. They are not encrypted unless explicitly wrapped as a JWE (JSON Web Encryption) per RFC 7516. A signed JWT's payload is base64url-encoded, not encrypted — the claims within it are readable by anyone who intercepts the token. Transmitting JWTs containing sensitive PII without transport-layer encryption or JWE violates data minimization principles.

Misconception: Refresh tokens are indefinitely valid.
Refresh tokens carry configurable lifetimes set by the authorization server. RFC 6749 §10.4 identifies refresh token compromise as a material security risk and recommends rotation. Sender-constrained refresh tokens (binding the token to a specific client via mutual TLS or DPoP per RFC 9449) address refresh token replay attacks that static bearer refresh tokens cannot prevent.

Misconception: OIDC and SAML are interchangeable.
While both support federated SSO, their token formats, binding mechanisms, and trust models differ structurally. SAML assertions are XML-signed, session-centric, and browser-redirect-driven. OIDC tokens are JWTs, API-friendly, and REST-compatible. Substituting one for the other requires architectural changes to the relying party, not just configuration adjustment. For practitioners navigating these distinctions, the how-to-use-this-identity-security-resource page describes how the provider network categorizes protocol-level topics.

Checklist or Steps (Non-Advisory)

The following represents the structural phases of an OAuth 2.0 Authorization Code + PKCE flow, as defined across RFC 6749, RFC 7636, and OpenID Connect Core 1.0:

1. Client generates code verifier — A cryptographically random string of 43–128 characters is generated by the client.
2. Client derives code challenge — The code verifier is hashed using SHA-256 and base64url-encoded to produce the code challenge (S256 method, per RFC 7636 §4.2).
3. Authorization request — The client sends an authorization request to the authorization server endpoint, including response_type=code, client_id, redirect_uri, scope, state, and the code_challenge + code_challenge_method parameters.
4. User authentication and consent — The authorization server authenticates the end user (for OIDC flows) and presents a consent screen for the requested scopes.
5. Authorization code issued — The authorization server redirects the user agent to the redirect_uri with a short-lived authorization code and the state parameter.
6. State validation — The client verifies that the returned state matches the value sent in step 3 to prevent CSRF attacks (RFC 6749 §10.12).
7. Token request — The client sends a POST request to the token endpoint, providing the authorization code, redirect_uri, client_id, and the code_verifier (not the challenge — the server computes the challenge for comparison).
8. Token response — The authorization server validates the code verifier against the stored code challenge, and returns an access token, ID token (OIDC), and optionally a refresh token.
9. ID token validation — The client validates the ID token signature, iss, aud, exp, and nonce claims per OpenID Connect Core 1.0 §3.1.3.7.
10. UserInfo retrieval (optional) — The client may call the UserInfo endpoint using the access token to retrieve additional identity claims.
11. API access — The client presents the access token as a Bearer token in the Authorization header of API requests (RFC 6750).
12. Token refresh — When the access token expires, the client presents the refresh token to the token endpoint to obtain a new access token without repeating the full authorization flow.

Reference Table or Matrix