OAuth and OpenID Connect Security

OAuth 2.0 and OpenID Connect (OIDC) are the dominant authorization and authentication delegation frameworks in modern web, mobile, and API ecosystems. This page covers how these protocols are structured, the security failure modes most frequently exploited in production deployments, and the regulatory and standards landscape that governs their implementation. Professionals working across authentication and authorization security and API security best practices encounter these protocols at nearly every integration boundary.

Definition and scope

OAuth 2.0 is an authorization framework defined in RFC 6749 by the Internet Engineering Task Force (IETF). It enables a resource owner to grant a third-party client limited access to a protected resource without exposing credentials. OAuth 2.0 is strictly an authorization protocol — it does not define an authentication layer.

OpenID Connect (OIDC) extends OAuth 2.0 with an identity layer, introducing the ID Token (a JSON Web Token) that carries verified claims about the authenticated user. OIDC is specified by the OpenID Foundation and published as a formal specification suite at openid.net. The distinction matters operationally: systems that use OAuth 2.0 alone to assert user identity — rather than OIDC's dedicated ID Token — introduce a class of authentication confusion vulnerabilities documented by the Open Web Application Security Project (OWASP).

The scope of these protocols covers four principal actor categories:

1. Resource Owner — the end user or entity that owns the protected data
2. Client — the application requesting access on behalf of the resource owner
3. Authorization Server — the server that issues tokens after authenticating the resource owner and obtaining consent
4. Resource Server — the API or service hosting the protected resource, which validates tokens presented by the client

NIST Special Publication 800-63C (Digital Identity Guidelines: Federation and Assertions) (NIST SP 800-63C) addresses federated identity assertions, including OIDC, and classifies assertion types by assurance level. Federal agencies subject to FedRAMP are expected to align OIDC deployments with these guidelines.

How it works

OAuth 2.0 defines four grant types — authorization code, implicit, resource owner password credentials, and client credentials — each suited to different trust environments. The authorization code grant with PKCE (Proof Key for Code Exchange, defined in RFC 7636) is the pattern recommended for public clients, including single-page applications and mobile apps, because it mitigates authorization code interception attacks without requiring a client secret.

The authorization code flow proceeds through discrete phases:

1. The client redirects the resource owner to the authorization server with a request containing response_type=code, client_id, redirect_uri, scope, and a state parameter.
2. The authorization server authenticates the resource owner and presents a consent screen.
3. Upon approval, the authorization server issues an authorization code to the registered redirect_uri.
4. The client exchanges the authorization code for an access token and, when OIDC is in use, an ID Token, by making a back-channel POST request to the token endpoint — authenticating with its client credentials.
5. The access token is presented to the resource server in the Authorization: Bearer header per RFC 6750.

The state parameter provides CSRF protection during the redirect phase — a failure mode also covered under cross-site request forgery (CSRF) defenses. PKCE replaces the implicit grant for public clients; the OAuth Security Best Current Practice document (RFC 9700) explicitly deprecates the implicit grant and the resource owner password credentials grant due to documented token leakage and phishing risks.

Token lifetimes and scopes are critical control points. Access tokens should carry short expiration windows — the OAuth 2.0 for Browser-Based Apps best practice document recommends access token lifetimes of 15 minutes or fewer for high-sensitivity contexts — with refresh tokens used for session continuity under RFC 6749 §6.

Common scenarios

Single-Page Applications (SPAs): SPAs operating in the browser cannot store client secrets securely. The authorization code flow with PKCE and no client secret is the prescribed pattern. Token storage in localStorage exposes tokens to cross-site scripting; storage in HttpOnly cookies behind a backend-for-frontend (BFF) pattern limits this exposure — a consideration connected to session management security.

Mobile applications: Native apps registered as public clients use authorization code with PKCE, with the authorization request launched through the device's system browser rather than embedded WebViews. RFC 8252 (OAuth 2.0 for Native Apps) (RFC 8252) formalizes this requirement. Custom URI schemes for redirect handling introduce hijacking risk; claimed HTTPS redirect URIs mitigate this in iOS and Android environments.

Machine-to-machine (M2M): Service-to-service communication with no user present uses the client credentials grant. The client authenticates directly to the authorization server and receives an access token scoped to the specific API. This pattern is common in microservices security architectures.

Federated enterprise SSO: Enterprises using OIDC for single sign-on across business applications must validate ID Token claims including iss (issuer), aud (audience), exp (expiration), and nonce — each of which maps to a known attack class if omitted from validation logic.

Decision boundaries

Choosing between OAuth 2.0 alone and OIDC depends on whether identity claims are required. OAuth 2.0 access tokens authorize actions; OIDC ID Tokens authenticate users. Conflating these produces broken authentication (OWASP Top Ten, A07:2021) — covered in depth under OWASP Top Ten vulnerabilities.

Grant type selection follows client capability:

Token validation at the resource server must occur on every request. Accepting tokens without signature verification, issuer validation, or audience checking constitutes a broken access control failure. For deployments subject to PCI DSS, access controls governing cardholder data environments must meet requirements under PCI DSS Requirement 8 — which addresses authentication management for systems accessing account data. HIPAA-covered entities implementing OAuth-protected health APIs must align with HHS Office for Civil Rights security rule standards at 45 CFR §164.312.

Scope minimization is a structural control: tokens should carry only the permissions necessary for a specific operation. Overly broad scopes increase blast radius if a token is compromised — a principle aligned with least-privilege access documented in NIST SP 800-53 AC-6.

References

• IETF RFC 6749 — The OAuth 2.0 Authorization Framework
• IETF RFC 7636 — Proof Key for Code Exchange (PKCE)
• IETF RFC 6750 — OAuth 2.0 Bearer Token Usage
• IETF RFC 8252 — OAuth 2.0 for Native Apps
• IETF RFC 9700 — OAuth 2.0 Security Best Current Practice
• OpenID Foundation — OpenID Connect Core 1.0
• NIST SP 800-63C — Digital Identity Guidelines: Federation and Assertions
• NIST SP 800-53 Rev 5 — AC-6 Least Privilege
• PCI Security Standards Council — PCI DSS Document Library
• HHS — 45 CFR §164.312 (HIPAA Security Rule Technical Safeguards)
• OWASP — Top Ten (A07:2021 Identification and Authentication Failures)