How do I set up SSO for a new application from scratch?

Setting up SSO for a new application from scratch usually means choosing an identity protocol, picking an Identity Provider (IdP), registering your app with it, and then wiring your app to trust the IdP for login.

Here’s a practical end-to-end checklist.

1) Decide the SSO protocol

For most new web apps, use OpenID Connect (OIDC) on top of OAuth 2.0.

• Use OIDC for:
  • web apps
  • SPAs
  • mobile apps
  • modern API-backed apps
• Use SAML only if:
  • you need enterprise compatibility with older IdPs
  • your customers explicitly require it

Recommendation: start with OIDC Authorization Code Flow with PKCE.

---

2) Pick your Identity Provider

Choose an IdP such as:

• Okta
• Auth0
• Azure AD / Entra ID
• Google Workspace
• OneLogin
• Keycloak (self-hosted)

You’ll configure your app as a “client” in that IdP.

---

3) Define your app’s auth requirements

Before coding, decide:

• Who can log in? anyone in a tenant, only specific domains, only invited users?
• Do you need:
  • email
  • name
  • groups/roles
  • tenant/org ID
• What session duration do you want?
• Do you need MFA enforced by the IdP?
• Will you support single-tenant or multi-tenant login?

---

4) Register the app in the IdP

In the IdP console, create a new OIDC application.

You’ll typically configure:

• Application type
  • Web app
  • SPA
  • Native/mobile
• Redirect URI(s)
  • e.g. https://app.example.com/auth/callback
• Post logout redirect URI
  • e.g. https://app.example.com/
• Allowed origins / CORS
  • if needed for SPA
• Grant type
  • Authorization Code
  • PKCE for public clients
• Scopes
  • usually openid email profile
• Claims / mappers
  • to include groups, roles, or tenant info if needed

The IdP will give you:

• Client ID
• possibly Client Secret
  • for confidential server-side apps
  • not for SPAs/mobile apps
• Issuer URL
• Discovery URL / metadata URL:
  • https://իդp.example.com/.well-known/openid-configuration

---

5) Implement the login flow

For a server-side web app

Use:

1. User clicks “Sign in”
2. Your app redirects user to IdP authorization endpoint
3. User authenticates at IdP
4. IdP redirects back to your callback URL with an authorization code
5. Your backend exchanges the code for tokens
6. Your app validates the ID token and creates its own session

For SPAs

Use:

1. Redirect to IdP
2. Use Authorization Code + PKCE
3. Receive code in the front end
4. Exchange code for tokens via PKCE
5. Prefer storing tokens securely; avoid localStorage if possible

---

6) Validate tokens properly

Your app should verify:

• signature
• issuer (iss)
• audience (aud)
• expiration (exp)
• nonce (for ID tokens, if used)
• not-before (nbf) if present

Also use the IdP’s JWKS endpoint to verify signatures:

• key rotation should be handled automatically

---

7) Create a local user session

Usually the IdP authenticates the user, but your app still needs its own session.

Best practice:

• create your app session after successful OIDC login
• store session in a secure, HTTP-only cookie
• map the external identity to an internal user record

Typical user identity fields:

• sub from OIDC token as the stable unique identifier
• email
• name
• groups/roles if needed

---

8) Handle user provisioning

Decide how users get created in your app:

Just-in-time provisioning

• create the user the first time they log in

Pre-provisioning

• create users ahead of time from directory sync / SCIM / admin tools

SCIM

If you need enterprise user lifecycle management:

• integrate SCIM for automated provisioning/deprovisioning
• often used with Okta/Azure AD

---

9) Map roles and permissions

SSO answers “who are you?” Your app still needs “what can you do?”

Options:

• map IdP groups to app roles
• map claims like roles or groups
• maintain app-specific permissions internally

Be careful:

• don’t trust user-provided roles from the client
• enforce authorization on the backend

---

10) Add logout

There are usually two layers:

• App logout
  • end your local session
• IdP logout
  • optionally redirect to the IdP’s end-session endpoint

Note:

• global logout across apps is not always immediate
• other app sessions may remain active depending on the IdP

---

11) Secure it

Important security practices:

• use HTTPS everywhere
• use Authorization Code Flow, not implicit flow
• use PKCE for public clients
• protect against CSRF on login and logout endpoints
• validate redirect URIs strictly
• store client secrets securely
• use short-lived access tokens
• use refresh tokens only if necessary
• rotate secrets
• log auth events without leaking tokens

---

12) Test the full lifecycle

Test:

• first login
• returning login
• expired session
• token expiration/refresh
• logout
• disabled user
• user removed from group
• email change
• IdP outage / degraded mode
• account linking if users may sign in from multiple IdPs

---

13) Example architecture

A common setup:

• Frontend: redirects user to IdP
• Backend:
  • handles callback
  • validates tokens
  • creates app session
  • authorizes actions
• IdP:
  • authenticates users
  • provides claims
  • enforces MFA / password policies

---

14) If you’re starting from zero, the simplest good path is:

1. Choose OIDC
2. Pick an IdP
3. Register a web app client
4. Use Authorization Code Flow + PKCE
5. Validate ID token on your backend
6. Create local session
7. Map external user to internal user
8. Add roles/groups later if needed

---

If you want, I can also give you:

• a provider-agnostic step-by-step implementation
• a sample OIDC flow diagram
• or a concrete setup guide for Okta/Auth0/Azure AD/Keycloak