OAuth 2.0 and OpenID Connect: Secure API Access

Best Practice: OAuth 2.0 and OpenID Connect

OAuth 2.0 (IETF RFC 6749) is the standard framework for delegated authorization: it lets an application obtain limited access to a resource on a user's behalf using access tokens, without handling the user's password. OpenID Connect (OIDC), published by the OpenID Foundation in 2014, layers authentication on top of OAuth 2.0 by adding an ID token (a JWT) that proves who the user is. Together they power most modern API security and single sign-on. The distinction matters: OAuth answers "what may this app do," OIDC answers "who is this user." Misusing one for the other is a common and dangerous mistake.

Step-by-Step Implementation Guidance

Use the Authorization Code flow with PKCE for web and mobile apps; PKCE is now recommended for all clients.
Use the Client Credentials flow for machine-to-machine API access with no user present.
Never use the deprecated Implicit or Resource Owner Password grants in new systems.
Use OIDC ID tokens for authentication and access tokens only for authorization.
Validate tokens fully: signature, issuer, audience, and expiry; fetch keys from the provider's JWKS endpoint.
Request the least scopes needed and keep access tokens short-lived; use refresh tokens with rotation.
Store tokens securely (HTTP-only cookies or secure storage), never in plain local storage for sensitive apps.

Common Mistakes Teams Make When Ignoring This Practice

Using access tokens to identify users instead of ID tokens.
Adopting the deprecated Implicit grant and exposing tokens in URLs.
Skipping signature, audience, or expiry validation on tokens.
Requesting overly broad scopes and issuing long-lived access tokens.
Rolling a custom auth scheme instead of using a vetted provider.

Tools and Techniques That Support This Practice

Identity providers: Auth0, Okta, Keycloak, Microsoft Entra ID, Google Identity.
JWT libraries with JWKS support for token validation.
PKCE-capable client SDKs (AppAuth).
Standards: RFC 6749, RFC 7636 (PKCE), and the OAuth 2.0 Security Best Current Practice (RFC 9700).

How This Practice Applies to Different Migration Types

Cloud Migration: Centralizing on an OIDC provider replaces per-app credentials as workloads move.
Database Migration: Token-based access decouples identity from any user table you are reshaping.
SaaS Migration: SSO via OIDC is the standard way to integrate users with a new SaaS provider.
Codebase Migration: Externalizing auth to a provider removes hand-rolled login code during a rewrite.

Checklist

Authorization Code flow with PKCE used for user-facing apps.
Client Credentials used for machine-to-machine.
Implicit and Password grants avoided.
ID tokens used for authentication, access tokens for authorization.
Tokens validated for signature, issuer, audience, and expiry.
Least-privilege scopes and short-lived tokens with rotation.
Tokens stored securely.

OAuth 2.0 and OpenID Connect