OAuth 2.0 and OpenID Connect

OAuth 2.0 lets a client obtain an access token to call an API on a user's behalf without seeing their password. OpenID Connect (OIDC) adds authentication on top: an ID token (a JWT about the user) and standard discovery and user-info endpoints. The recommended flow for web, mobile and SPA clients is Authorization Code with PKCE; the implicit and password grants are deprecated (OAuth 2.1). Machine-to-machine calls use the client credentials grant.

Authorization Code + PKCE
1. Client creates code_verifier (random) and code_challenge = BASE64URL(SHA256(verifier))
2. Browser → GET /authorize?response_type=code&client_id=...&redirect_uri=...
            &scope=openid profile orders:read&state=xyz&code_challenge=...&code_challenge_method=S256
3. User logs in at the identity provider, consents
4. IdP → redirect_uri?code=AUTH_CODE&state=xyz        (client checks state)
5. Client → POST /token {grant_type=authorization_code, code, redirect_uri, code_verifier}
6. IdP → {access_token, id_token, refresh_token, expires_in}
7. Client → API with Authorization: Bearer <access_token>; API validates signature, iss, aud, exp, scopes

Common pitfalls

• Using the ID token to call APIs (it's for the client, the access token is for APIs).
• Skipping state/PKCE checks.
• Wildcard redirect URIs enabling token theft.

Key points

• OAuth = delegated authorization; OIDC = authentication
• Authorization Code + PKCE for all user-facing clients
• APIs validate issuer, audience, expiry and scopes

Further reading: oauth.net: OAuth 2.0