OAuth and OpenID Connect Security

OAuth 2.0 and OpenID Connect (OIDC) are the dominant authorization and authentication delegation frameworks in modern application architectures, governing how applications request access to protected resources on behalf of users without exposing credentials. Misconfigurations in these protocols represent a documented attack surface that spans web applications, mobile clients, and API gateways. This page covers the definitional boundaries between OAuth and OIDC, the technical mechanics of each flow, common deployment scenarios, and the decision criteria that govern which grant type or flow applies to a given architectural context.

Definition and scope

OAuth 2.0 is an authorization framework, not an authentication protocol. It defines a mechanism by which a resource owner (a user) grants a third-party application (a client) limited access to a protected resource hosted by a resource server, mediated by an authorization server — without sharing credentials. The specification is published by the Internet Engineering Task Force (IETF) as RFC 6749, with bearer token handling defined in RFC 6750.

OpenID Connect is an identity layer built on top of OAuth 2.0, standardized by the OpenID Foundation. Where OAuth issues access tokens to authorize API calls, OIDC issues ID tokens — JSON Web Tokens (JWTs) that assert the authenticated identity of the user. OIDC is the mechanism that enables single sign-on (SSO) across domains; OAuth alone does not establish who the user is.

The scope of both protocols extends across web applications, native mobile clients, single-page applications (SPAs), server-side APIs, and machine-to-machine (M2M) service integrations. Federal guidance from the National Institute of Standards and Technology (NIST) Special Publication 800-63C governs federation assurance levels, which directly apply to OIDC deployments in government and regulated-sector applications. NIST SP 800-63C defines three Federation Assurance Levels (FAL1, FAL2, FAL3) corresponding to increasing requirements for token protection and assertion binding.

Security researchers profiling the OWASP API Security Top 10 consistently list broken object-level authorization and broken authentication — both directly tied to OAuth and OIDC misconfigurations — among the highest-risk vulnerabilities in deployed APIs. Application security professionals working across this domain will find structured providers at Application Security Providers.

How it works

OAuth 2.0 defines 4 core grant types, each suited to a distinct client capability and trust level:

1. Authorization Code Grant — The client redirects the user to the authorization server, receives a short-lived authorization code, then exchanges it server-side for an access token. This is the most secure flow because tokens are never exposed to the user agent. The OAuth 2.0 Security Best Current Practice (RFC 9700) mandates use of PKCE (Proof Key for Code Exchange, RFC 7636) for all authorization code flows, including those with confidential clients.
2. Client Credentials Grant — Used for M2M communication where no user is present. The client authenticates directly to the authorization server with its own credentials and receives an access token scoped to its service identity.
3. Device Authorization Grant (RFC 8628) — Designed for input-constrained devices (smart TVs, CLI tools) that cannot open a browser. The device displays a user code; the user authenticates on a secondary device.
4. Implicit Grant — Historically used for SPAs; deprecated in OAuth 2.1 draft specifications due to token exposure risks in the browser's URL fragment. RFC 9700 explicitly discourages this flow.

The OIDC layer adds a fifth artifact: the ID Token, a signed JWT containing claims including sub (subject identifier), iss (issuer), aud (audience), and exp (expiration). Authentication events must validate all five of these claims, as specified in the OpenID Connect Core 1.0 specification.

The authorization server functions as the trust anchor in this architecture. Token lifetimes, scope restrictions, and revocation policies are all administered at this layer. Access tokens should be short-lived — the OAuth 2.0 for Native Apps guidance (RFC 8252) recommends treating access token lifetimes as an operational security parameter rather than a convenience setting.

Common scenarios

Enterprise SSO with OIDC: An employee authenticates once to an identity provider (IdP) such as one complying with SAML or OIDC federation standards. Downstream applications receive ID tokens issued by the IdP, validated against the IdP's published JWKS (JSON Web Key Set) endpoint. NIST SP 800-63C FAL2 requires that assertions be encrypted in transit and that the RP (relying party) authenticate to the IdP.

Third-party API access (delegated authorization): A mobile application requests read access to a user's calendar data hosted by a separate service. The application uses the Authorization Code + PKCE flow, obtaining a scoped access token valid for a defined duration. The resource server validates the token's aud and scope claims on every request. This scenario is central to .

Machine-to-machine microservice communication: Internal services authenticate using the Client Credentials grant. Token introspection (RFC 7662) or JWT local validation is used to authorize service-to-service calls. Scope restriction limits blast radius if a service credential is compromised.

Healthcare and financial sector OIDC: The HL7 SMART on FHIR framework — referenced by the Office of the National Coordinator for Health IT (ONC) in 45 CFR Part 170 interoperability rules — uses OIDC and OAuth 2.0 as the foundational authorization layer for patient-facing health application access. Financial-grade API (FAPI) profiles published by the OpenID Foundation extend OAuth 2.0 with mandatory PKCE, PAR (Pushed Authorization Requests), and certificate-bound access tokens for open banking contexts.

Decision boundaries

Selecting between OAuth-only, OIDC, or a specific grant type requires mapping four parameters: client type, user presence, trust level, and regulatory obligation.

OAuth vs. OIDC: If the application needs to verify user identity — log in, SSO, profile retrieval — OIDC is required. If the application only needs to act on a resource (read files, post to an API) without knowing who the user is, OAuth access tokens are sufficient. Treating an access token as proof of identity is a documented vulnerability class; the ID token exists precisely to prevent this conflation.

Grant type selection:

Regulatory triggers: Applications subject to HIPAA (administered by HHS), FedRAMP (GSA/OMB), or PCI DSS must map their OAuth/OIDC configuration to the relevant control frameworks. NIST SP 800-53 Rev 5 control family IA (Identification and Authentication), specifically IA-8 (Identification and Authentication for Non-Organizational Users), directly governs federated identity mechanisms in federal information systems.

Token validation: Every relying party must independently validate token signatures, expiration, issuer, and audience. Delegation of this validation to a reverse proxy does not eliminate the application-layer obligation. The OpenID Connect Core 1.0 specification section 3.1.3.7 enumerates the 12 validation steps required for ID token verification.

The Application Security Authority resource provides context on how practitioners navigate these frameworks within the broader application security service landscape.