OAuth 2.0 and OpenID Connect Explained Simply

OAuth 2.0 lets an app get limited access to an API on a user's behalf without seeing their password ("let this app read my calendar"). OpenID Connect (OIDC) builds on OAuth to tell the app who the user is ("Sign in with Google").

The roles

• Resource owner - the user.
• Client - your application.
• Authorization server - issues tokens (Google, Microsoft, Auth0, Keycloak, your own).
• Resource server - the API the token grants access to.

Authorization code flow with PKCE

1. Your app creates a random code verifier and its SHA-256 hash, the code challenge.
2. It redirects the user to the authorization server with the challenge, requested scopes and a random state value.
3. The user signs in there and approves access.
4. The server redirects back to your app with a short-lived authorization code.
5. Your server exchanges the code plus the original verifier for tokens.

GET https://accounts.example.com/authorize
  ?response_type=code
  &client_id=shop-web
  &redirect_uri=https://shop.example.com/callback
  &scope=openid%20email%20profile
  &state=xyz123
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

PKCE ensures that a stolen authorization code is useless without the verifier. It's recommended for all clients, and required for mobile and single-page apps that can't keep a client secret.

The tokens

• Access token - sent to APIs (Authorization: Bearer ...). Short-lived.
• Refresh token - used to get new access tokens without asking the user again. Keep it secret.
• ID token (OIDC only) - a JWT describing the user (sub, email, name) for your app; don't send it to APIs.

Common mistakes

• Using the implicit flow (tokens in the URL); it's deprecated.
• Skipping the state check, which enables login CSRF.
• Identifying users by email instead of the stable sub claim plus issuer.
• Requesting more scopes than needed.
• Not validating ID token signature, issuer, audience and expiry; use a certified library.