OAuth Authorization Code + PKCE: How the Flow Works
Follow a sign-in request from the application through a one-time code, PKCE verification, and the application session.
An authorization code is a short-lived handoff, not a token to keep in the browser. PKCE connects that handoff to the login attempt that started it.
The flow in one pass
- The application creates a fresh random
stateand PKCE verifier, and stores them with a short-lived login transaction. - It derives an S256 challenge from the verifier and sends the browser to the authorization endpoint with the client ID, registered redirect URI, requested scopes, state, and challenge.
- Bhauu Auth hosts sign-in and authorization. After the user completes them, the browser returns to the registered callback with a one-time code and state.
- The application checks the returned state against its stored transaction before exchanging the code. The exchange sends the original verifier; the server checks that it matches the earlier challenge.
- The application uses the resulting scoped access where appropriate and establishes its own local session. The code itself is never that session.
A useful mental model is application -> hosted sign-in -> exact callback -> code exchange -> application session. The browser may carry the short-lived code through the callback; it should not be used as a vault for long-lived credentials.
What state and PKCE each protect
state ties the callback to the browser's pending request. Reject a missing or mismatched value before attempting an exchange. PKCE ties the code to the original verifier. The challenge travels in the authorization request; the verifier stays with the transaction until the token exchange. They solve related but different problems, so neither replaces the other.
How Bhauu Auth applies it
Bhauu Auth uses Authorization Code with required PKCE S256 and an exact registered redirect URI. Its documented public scopes include profile and email. A client that needs user claims uses the documented UserInfo contract; an access token is not an ID token. Do not build an OpenID Connect assumption into this flow.
For concrete request fields, verifier generation, and callback handling, follow the Getting Started guide, OAuth documentation, and PKCE S256 guide.
Takeaway
Keep state and the verifier together for one attempt, validate the callback, exchange the one-time code, then manage the application's own session separately.