I’m building a multi-tenant app and need OIDC-based SSO

Got it — for a multi-tenant app, OIDC-based SSO is usually the right choice.

Recommended approach

1) Use a separate OIDC configuration per tenant

Each tenant can have:

• its own issuer
• client credentials
• redirect URI(s)
• scopes / claims mapping
• logout endpoint

This is the cleanest option if tenants bring their own IdP (common in B2B SaaS).

2) Support dynamic tenant discovery

At login time, identify the tenant via:

• subdomain (acme.yourapp.com)
• path (yourapp.com/t/acme)
• email domain
• explicit tenant selection screen

Then load that tenant’s OIDC settings.

3) Map OIDC identity to your internal user model

Store:

• tenant_id
• issuer
• subject (sub)
• email
• name
• groups/roles claims if needed

Use (tenant_id, issuer, sub) as the stable identity key.

4) Validate tokens carefully

For ID tokens / access tokens:

• verify signature against the tenant’s JWKS
• validate iss, aud, exp, nonce
• enforce the expected tenant config
• never trust just the email claim for identity

5) Support JIT provisioning

On first login:

• create user if not present
• assign default tenant role
• optionally map IdP groups to app roles

6) Handle logout thoughtfully

OIDC logout is inconsistent across providers, so decide whether you need:

• app session logout only
• RP-initiated logout
• federated logout

Architecture pattern

A common setup is:

• Tenant config service: stores each tenant’s OIDC metadata
• Auth gateway / auth module: handles discovery and callback
• User directory: maps OIDC identities to app users
• Session layer: issues your own app session after OIDC sign-in

Important pitfalls

• Avoid a single global OIDC client if each tenant has different IdPs.
• Don’t reuse redirect URIs across tenants unless your app can safely route by state.
• Don’t assume one email equals one user across tenants.
• Be prepared for providers that omit email or use non-verified emails.
• Watch for claim differences: Azure AD, Okta, Auth0, Keycloak, Google all behave differently.

If you want the simplest robust design

Use:

• OIDC Authorization Code Flow with PKCE
• tenant-specific issuer/client config
• app-owned session after login
• strict token validation
• per-tenant user mapping

If you want, I can help you with one of these next:

1. a reference architecture
2. a database schema
3. an OIDC login flow diagram
4. sample code for Node/Python/Java/.NET
5. guidance for Azure AD / Okta / Auth0 / Keycloak