I'm building enterprise login into an existing app. What SSO architecture should I use?

For an enterprise login in an existing app, the best default architecture is:

Use an external Identity Provider with OIDC, and keep your app as a relying party

• Preferred protocol: OpenID Connect (OIDC) on top of OAuth 2.0
• Common enterprise IdPs: Okta, Azure AD / Entra ID, Ping, Auth0, Google Workspace, ADFS (if legacy)
• Your app’s role: trust the IdP for authentication, create a local session after callback

This is usually the best choice because it’s:

• widely supported
• easier to integrate than SAML
• better suited for modern web/mobile apps
• simpler to use with APIs, SPAs, and mobile clients

---

Recommended architecture

1. Browser / client starts login

User clicks “Sign in with SSO” in your app.

2. Redirect to the enterprise IdP

Your app sends the user to the IdP’s authorization endpoint using:

• Authorization Code flow
• PKCE if it’s a public client / SPA / mobile app

3. IdP authenticates the user

The IdP handles:

• password / MFA
• conditional access
• device checks
• federation to upstream corporate directory if needed

4. IdP returns an authorization code

Your app receives the code on the callback URL.

5. Backend exchanges code for tokens

Your backend validates:

• issuer
• audience
• signature
• nonce / state
• expiration

Then it creates:

• a local app session cookie for web apps, or
• a short-lived app JWT/session for API-driven apps

6. App maps identity to local user record

Use stable claims like:

• sub for unique user identifier
• email only as a convenience, not the primary key
• optionally groups, roles, tenant, upn

7. Access control is enforced in your app

Use IdP claims plus your own app authorization model:

• groups/roles from IdP
• local entitlements
• tenant/org mapping
• SCIM-provisioned users if needed

---

If you need enterprise features, add these components

A. SSO gateway / authentication service

Put a thin auth layer in front of your app if the app is legacy or hard to change:

• handles OIDC/SAML integration
• centralizes session handling
• normalizes claims
• issues app-specific cookies/tokens

This is useful when:

• you have multiple apps
• the app is monolithic/legacy
• you need to support both SAML and OIDC
• you want a single auth implementation

B. User provisioning via SCIM

For larger enterprises, SSO alone is often not enough. Add:

• SCIM 2.0 for automated user/group provisioning and deprovisioning
• supports joiner/mover/leaver lifecycle
• helps keep access synced with HR / IAM

C. Central authorization model

Don’t rely only on “authenticated = authorized.” Use:

• RBAC for simple role-based access
• ABAC/policy checks for more complex enterprise permissions
• tenant/org mapping to prevent cross-customer access

---

OIDC vs SAML: which should you choose?

Choose OIDC if:

• you’re building new login for web/mobile/API
• you want simpler modern integration
• you have SPAs or native apps
• you need token-based API access

Choose SAML if:

• the customer’s enterprise only supports SAML for this app
• you’re integrating with older enterprise IAM stacks
• the app is an older enterprise web app

Practical advice:

• If possible, support OIDC first
• If your customers demand it, add SAML as a second protocol
• Many enterprise SaaS apps support both

---

Common architecture patterns

Pattern 1: Direct-to-IdP login

Best for modern apps.

• app redirects directly to the enterprise IdP
• app validates OIDC tokens
• app manages its own session

Pattern 2: Central auth broker

Best when supporting many IdPs/protocols.

• your broker talks OIDC/SAML to customer IdPs
• your app only talks to your broker
• good for multi-tenant enterprise SaaS

Pattern 3: BFF (Backend for Frontend)

Best for SPAs.

• browser never stores access tokens directly
• backend handles code exchange and token storage
• frontend uses secure session cookie to talk to backend
• reduces token exposure in the browser

---

Security requirements you should include

• Authorization Code + PKCE
• strict redirect URI allowlisting
• validate state, nonce, issuer, audience
• short-lived access tokens
• refresh token rotation if used
• secure, HttpOnly, SameSite cookies for web sessions
• MFA/conditional access delegated to IdP
• logout handling, but don’t overpromise “global logout” unless your IdP supports it well
• audit logs for login, token issuance, admin actions

---

If you’re an enterprise SaaS vendor

A good default enterprise SSO package is:

• OIDC for authentication
• SAML optional for compatibility
• SCIM for provisioning
• group/role mapping
• multi-tenant org mapping
• optional JIT provisioning on first login
• centralized auth service if you support multiple apps

---

My recommendation in one line

Use OIDC Authorization Code + PKCE with a backend session, add SCIM for provisioning, and support SAML only if customer requirements force it.

If you want, I can also sketch:

1. a reference architecture diagram,
2. the exact login flow for SPA vs server-rendered apps, or
3. a build-vs-buy decision for Auth0/Okta/Azure AD integration.