The browser sends a request to your SP — your application. Simple.

Before doing anything else, your SP generates two values:

• code_verifier — a cryptographically random string, 43–128 characters, high entropy, completely unpredictable.
• code_challenge — derived from the verifier by hashing it with SHA-256 and encoding as Base64URL.

code_challenge = BASE64URL(SHA256(code_verifier))

The redirect points to the IdP’s /authorize endpoint with these query parameters:

response_type=code
client_id=YOUR_APP_ID
redirect_uri=https://yourapp.com/callback
scope=openid profile email
state=RANDOM_CSRF_VALUE
nonce=RANDOM_REPLAY_VALUE
code_challenge=BASE64URL_HASH
code_challenge_method=S256

The openid scope is what turns this into an OIDC request. state is CSRF protection. nonce prevents ID token replay attacks.

The browser makes a GET request to the IdP’s /authorize endpoint. The user is now on the IdP’s domain — not yours. Your app never sees the user’s password.

The IdP renders an HTML login form on its own domain. Your SP cannot intercept the password. The trust is entirely in the IdP.

A POST request goes to the IdP with the username and password.

This internal step can include: verifying the password hash, triggering MFA (TOTP, push notification, hardware key), checking device trust policies, evaluating risk signals (unusual location, new device), and verifying account status. All of this must pass before proceeding.

The IdP shows the user exactly what scopes the application is requesting: “Application X wants access to your name, email, and profile picture.” For enterprise apps with admin pre-authorization, this step is skipped. For consumer OAuth, the user must explicitly approve.

The user clicks Allow.

The IdP generates a short-lived, single-use authorization code — valid for ~10 minutes, usable exactly once. Think of it as a claim ticket at a coat check. It’s not the coat; it’s the ticket to get the coat. The IdP sends a 302 redirect to your SP’s redirect_uri:

https://yourapp.com/callback?code=AUTH_CODE&state=xyz

The code traveled through the browser (visible in the URL). That’s fine — it’s worthless without the code_verifier, and it expires in 10 minutes.

The browser follows the redirect and hits your SP’s callback URL with code and state in the query string. Your SP now has the authorization code.

Before doing ANYTHING with the code, your SP must verify that the state value matches what it generated in Step 3. This is CSRF protection. If an attacker tried to trick your app into making a forged OAuth request, the state wouldn’t match.

This does NOT go through the browser. Your SP makes a direct HTTPS POST to the IdP:

POST /token HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE
&client_id=YOUR_APP_ID
&client_secret=YOUR_APP_SECRET
&redirect_uri=https://yourapp.com/callback
&code_verifier=ORIGINAL_RANDOM_STRING

The code_verifier is being sent for the first time here — it has never appeared in a browser URL. It went from your SP’s memory directly to the IdP’s server over HTTPS.

The IdP takes the code_verifier you sent, runs it through SHA256(), Base64URL-encodes it, and compares it against the stored code_challenge from Step 3:

SHA256(code_verifier) == stored_code_challenge ?

If yes — proceed. If no — reject (stolen code attempt). The IdP also verifies the code hasn’t expired, hasn’t already been used, and that the client_id and redirect_uri match.

If all checks pass, the IdP returns a JSON object with three tokens:

{
  "access_token":  "eyJ...",   // Short-lived JWT (5–60 min)
  "id_token":      "eyJ...",   // OIDC identity JWT
  "refresh_token": "dGhp...",  // Long-lived, for silent renewal
  "token_type":    "Bearer",
  "expires_in":    3600
}

These tokens never touched the browser. They went directly from IdP to SP, server-to-server.

The id_token is a JWT with three Base64URL-encoded parts separated by dots: header, payload, signature. Your SP must verify, in order:

• Signature — verified with the IdP’s public key. Tampered? Reject.
• iss (issuer) — must match the IdP’s URL.
• aud (audience) — must include your SP’s client_id.
• exp (expiry) — current time must be before exp.
• iat (issued at) — must be in the past, not the future.
• nonce — must match the nonce sent in Step 3. Prevents replay attacks.
• at_hash — hash of the access_token, if present.

To verify the signature, your SP fetches the IdP’s public keys from its JWKS (JSON Web Key Set) endpoint — typically at /.well-known/jwks.json. The kid field in the JWT header identifies which key to use. These keys are cached; you don’t refetch on every login, only when keys rotate.

Your SP may call the IdP’s /userinfo endpoint with the access_token as a Bearer token to receive richer profile claims: full name, email, profile picture, locale, and custom attributes. The ID token has a fixed size limit; /userinfo is the channel for extended data.

GET /userinfo HTTP/1.1
Authorization: Bearer {access_token}

Your SP now has everything it needs. It creates a server-side session or issues its own application-level tokens (e.g., a session cookie). The user is redirected to their destination. The entire OAuth/OIDC dance is invisible to them — they simply “logged in.”

The user clicks something — views their profile, loads a dashboard. The browser sends a request to your SP.

Your SP attaches the access_token as a Bearer token and calls the protected API:

GET /api/resource HTTP/1.1
Authorization: Bearer {access_token}

Because JWTs are self-contained, the Resource Server can validate the access_token without calling the IdP. It verifies the JWT signature with the cached public key, checks exp, confirms aud matches its own identifier, and checks scope claims match what this endpoint requires. No network call to the IdP — this is why JWTs are so powerful in microservice architectures.

All checks pass — 200 OK, here’s your data.

When the SP gets a 401 or detects the access token is near expiry, it POSTs to the IdP’s /token endpoint silently:

grant_type=refresh_token
&refresh_token={stored_refresh_token}
&client_id=YOUR_APP_ID
&client_secret=YOUR_APP_SECRET

The IdP returns a new access_token and a NEW refresh_token. The old refresh token is immediately invalidated.