OAuth 2.0 and OpenID Connect explained

How delegated authorization and single sign-on work: OAuth roles, the authorization code flow with PKCE, scopes, access and refresh tokens, client credentials for services, OpenID Connect ID tokens, enterprise SSO with SAML and OIDC, and designing an identity service.

Reading is half of it. See this used in a real interview: walk through Design Slack →

"Sign in with Google", "allow this app to read your calendar", corporate single sign-on and third-party API access all rely on OAuth 2.0 and OpenID Connect (OIDC). They are easy to misuse because the two are often confused: OAuth grants an app access to an API on a user's behalf; OIDC adds a standard way to learn who the user is. Interviews touch on them when designing login, developer platforms or integrations.

OAuth roles

• Resource owner: the user.
• Client: the app that wants access (a web app, mobile app, or third-party integration).
• Authorization server: issues tokens after the user authenticates and consents (Google, Okta, your own identity service).
• Resource server: the API that accepts access tokens.

The point of OAuth: the client never sees the user's password, and access is limited by scopes (calendar.read) and can be revoked.

The authorization code flow with PKCE

The standard flow for web and mobile apps:

1. The client generates a random code verifier and its hash, the code challenge (PKCE).
2. It redirects the user to the authorization server with its client id, requested scopes, redirect URI, a random state value and the code challenge.
3. The user logs in and consents.
4. The authorization server redirects back with a short-lived authorization code (and the state, which the client checks to prevent CSRF).
5. The client exchanges the code, plus the code verifier, at the token endpoint for an access token (and usually a refresh token).
6. The client calls the API with the access token.

PKCE ensures that a stolen authorization code is useless without the verifier, which is why it is now recommended for all clients, not only mobile apps. Older flows (implicit, resource owner password) are discouraged.

Tokens

• Access token: short-lived, sent to APIs. Either a JWT the API verifies locally, or an opaque token the API checks via introspection. See JWT vs session cookies.
• Refresh token: long-lived, used to obtain new access tokens; stored securely, rotated, revocable.
• Scopes limit what the access token can do; the API enforces them.

Machine to machine

The client credentials flow lets a service obtain a token for itself (no user), using its own credentials or a signed assertion. Used for backend integrations and partner APIs. Internal service-to-service traffic may instead use mTLS identities from a service mesh. See service discovery and service mesh.

OpenID Connect

OIDC is a layer on top of OAuth for authentication:

• Requesting the openid scope returns an ID token: a JWT describing the user (subject id, issuer, audience, issue time, optionally email and name), signed by the identity provider.
• The client validates the ID token's signature, issuer, audience, expiry and nonce, then logs the user in.
• A standard userinfo endpoint and discovery document (with signing keys) make integration uniform across providers.

Rule of thumb: use the ID token to know who logged in; use the access token to call APIs. Never use an access token as proof of identity in your own app.

Enterprise SSO

Business customers want employees to log in with their company identity provider (Okta, Microsoft Entra ID, Google Workspace):

• SAML (older, XML-based) and OIDC are the two protocols to support.
• Per-tenant configuration maps an email domain or tenant to its identity provider.
• SCIM provisioning creates and deactivates accounts automatically when employees join or leave.
• Just-in-time provisioning creates accounts on first login.

See multi-tenancy and Design Slack.

Designing an identity service

If you build your own authorization server (or wrap a provider):

• Stateless token verification for APIs via published signing keys (JWKS), with key rotation.
• A session and refresh token store with revocation, rotation and reuse detection.
• Rate limits and abuse protection on login, token and password reset endpoints. See trust and safety.
• MFA and passkeys (WebAuthn) for stronger authentication.
• Consent records and a page where users can see and revoke connected apps.
• Audit logs of logins and token grants.
• High availability: if the identity service is down, nobody can log in; existing access tokens keep working until expiry, which is one reason to verify them locally.

Third-party developer platforms

If your product lets other developers build integrations (a payments API, a file storage API), OAuth is how users grant those apps access. Define granular scopes, require app registration with exact redirect URIs, show clear consent screens, and let users and admins revoke access. See Design a Payment System and Design Dropbox.

In the interview

"Users sign in through OIDC with the authorization code flow and PKCE; the app validates the ID token and creates its own session; API calls use short-lived access tokens verified locally by the gateway; enterprise tenants configure their own identity provider via SAML or OIDC, with SCIM provisioning."

Checklist

• OAuth for delegated API access; OIDC for login.
• Authorization code flow with PKCE and state; no implicit or password flows.
• Short access tokens, rotating refresh tokens, enforced scopes.
• Client credentials for machine-to-machine.
• ID tokens validated (signature, issuer, audience, expiry, nonce).
• Enterprise SSO via SAML and OIDC per tenant, with SCIM.
• Rate limits, MFA, consent management and audit logs.