SSO for SaaS applications
In short
For a SaaS application, use the Authorization Code flow with PKCE, allow-list your redirect URI, and request the smallest scope set that covers what you actually read.
- PKCE applies whether or not your client can keep a secret — use it either way.
- Register one redirect URI per environment; wildcards are not accepted.
- Start with openid profile email and add scopes only when a feature needs one.
The flow: Authorization Code with PKCE
- 1
Register the application
Create an app to get a client ID, then add one redirect URI for each environment you deploy. Codes are only ever returned to an allow-listed destination.
Full detail in the docs - 2
Send the user to authorize
Generate a verifier and an S256 challenge, then redirect with response_type=code, your client ID, the redirect URI, the scopes and the challenge.
Full detail in the docs - 3
Exchange the code
On the callback, verify the state parameter, then exchange the code together with the original verifier for tokens.
Full detail in the docs - 4
Read the claims you asked for
The ID token carries the claims covered by the scopes the user approved — and nothing beyond them.
Full detail in the docs
Common mistakes
- Requesting every scope at once. An unfamiliar consent screen is where sign-ups are lost.
- Skipping the state parameter, which is what protects the callback against CSRF.
- Putting a client secret in a front-end bundle. If the code ships to a browser, it is public.
SPA with PKCE
Open the guide