OAuth Flow Overview

CP-Auth implements the standard OAuth 2.0 Authorization Code Flow with PKCE (RFC 7636). External services choose between two entry-point modes.

Two UX modes

Mode	What the user sees	When to use	Guide
Self-hosted login	Only your app (no CP branding)	You need full brand control	Self-hosted login
CP-hosted page	The `auth.cp-platform.com` login page	Fastest integration with the least code	CP-hosted login page

Both modes share the same backend token-exchange step. The only difference is where the user sees the login UI.

Standard flow (Authorization Code + PKCE)

[1] User      → clicks "Sign in"
[2] App FE    → sends the user to CP-Auth or your own form
[3] User      → authenticates with email/password or a social provider
[4] CP-Auth   → redirects back to your callback URL with ?code=<authcode>&state=<csrf>
[5] App FE    → forwards the code to your backend
[6] App BE    → POST /oauth/token (client_secret + code + code_verifier)
[7] CP-Auth   → { access_token, refresh_token, expires_in }
[8] App BE    → stores access_token in an HttpOnly cookie and responds to the user

Who handles PKCE

Flow	PKCE verifier storage	Verifier passed at token exchange
Google / Kakao social	CP-Auth (server-side cookie)	Not needed — CP-Auth handles it
Email direct auth	External client (SDK does it automatically)	Required — send `code_verifier` to your backend
CP-hosted page redirect	CP-Auth (cookie)	Not needed

You only need to thread code_verifier through your backend in the self-hosted email flow. The SDK puts it in the onSuccess callback for you.

state · CSRF protection

The state parameter is used in every flow. The SDK generates and validates a random state automatically. If you call the endpoints directly, generate state yourself and verify equality on the callback.

Where to read next

You want users to never see a CP-branded page → Self-hosted login
You want the fastest path to production → CP-hosted login page
You need to know how to verify or refresh tokens → Token verification & refresh