How do I implement OIDC login for a B2B SaaS app?

Implementing OIDC login for a B2B SaaS app is mostly about combining secure user sign-in with organization-aware routing and authorization.

Here’s a practical way to think about it.

---

1) Pick the right OIDC flow

For a SaaS web app, the usual choice is:

• Authorization Code Flow with PKCE
  • Best for browser-based apps
  • Works for SPAs, server-rendered apps, and mobile
  • More secure than implicit flow

If you have a backend, use:

• Backend session cookie after OIDC login
• Keep tokens on the server when possible

---

2) Model the B2B problem correctly

In B2B SaaS, identity is usually:

• User identity = who the person is
• Tenant/organization identity = which company they belong to
• Authorization = what they can do in that company

Do not assume email domain equals tenant automatically. It can help for discovery, but it’s not authoritative.

Common entity model:

• User
• Organization
• Membership (user_id, organization_id, role)
• Identity / ExternalAccount
  • maps user_id to OIDC provider subject (iss, sub)

---

3) Understand what OIDC gives you

OIDC login gives you an identity assertion, usually in the ID token, and often user info via the userinfo endpoint.

Useful claims:

• sub — stable user identifier at the IdP
• email
• email_verified
• name
• preferred_username
• iss — issuer
• aud — audience
• exp, iat, nonce

For a robust system:

• Use iss + sub as the external identity key
• Don’t rely on email as the unique identifier
• Verify token signature, issuer, audience, nonce, and expiration

---

4) Decide how users find the right organization

This is one of the main B2B design problems. Common patterns:

A. Email-domain discovery

User enters alice@acme.com, you suggest Acme tenant.

Pros:

• Easy UX

Cons:

• Multiple orgs can share domains
• Domain is not always enough
• Invited users may use personal emails

B. Organization-first login

User selects or types company name first, then you redirect to that org’s IdP or login policy.

Pros:

• Good for enterprise SSO
• Clear routing

Cons:

• More friction for small businesses

C. Invite-based onboarding

User gets invited to a tenant; login happens after invitation acceptance.

Pros:

• Strong for B2B SaaS
• Simple access control

Cons:

• Needs onboarding flow

In practice, many products combine:

• Invite-based
• Email-domain discovery
• Org picker for users who belong to multiple tenants

---

5) Handle enterprise SSO properly

For B2B SaaS, tenants may bring their own IdP:

• Okta
• Microsoft Entra ID
• Google Workspace
• Ping, OneLogin, etc.

You usually support:

• A global login
• Plus per-organization OIDC settings
  • issuer URL
  • client ID/secret
  • allowed domains
  • enforced SSO or optional SSO

Typical behavior:

• If tenant has an IdP configured, redirect them there
• If not, use your default login provider
• Optionally support “login with email” to discover tenant first

---

6) Implement the login flow

High-level sequence

1. User clicks “Sign in”
2. Your app redirects to IdP authorization endpoint
3. IdP authenticates user
4. IdP redirects back with authorization code
5. Your backend exchanges code for tokens
6. Verify ID token
7. Create or update local user record
8. Create session
9. Redirect user to the app

Important security details

• Use state to prevent CSRF
• Use nonce to prevent token replay
• Use PKCE if public client or SPA
• Validate redirect URIs strictly
• Store secrets securely
• Rotate keys if using your own signing keys for sessions

---

7) Map identities to users

You need a durable mapping table like:

external_identities
- id
- user_id
- issuer
- subject
- email
- provider_name
- created_at

Lookup rule:

• Find user by (issuer, subject)
• If not found, create user if allowed
• If user already exists by email, link carefully only if policy allows it

Be careful:

• Email can change
• Two IdPs can issue same email
• One person may have multiple identities

---

8) Support provisioning and deprovisioning

B2B apps often need lifecycle management.

Provisioning options

• Just-in-time provisioning on first login
• SCIM for enterprise provisioning
• Manual invites by admins

Deprovisioning options

• Disable membership in your app
• Respect SCIM deactivation if supported
• Revoke sessions on logout or identity removal

If a user leaves an org:

• remove membership
• invalidate org-scoped sessions/refresh tokens if needed

---

9) Decide what tokens your app should store

For most SaaS web apps:

• Store your own session cookie
• Avoid exposing OIDC tokens to the browser unless necessary

If you need API access to downstream services:

• Store access token server-side
• Refresh using refresh token if provider supports it
• Keep token lifetime short

General rule:

• The ID token is for authentication, not API authorization
• Use access tokens only for API calls to resource servers

---

10) Authorization should be app-managed

OIDC authenticates the user; it does not solve your authorization model.

You still need:

• roles: owner, admin, member, viewer
• resource permissions
• organization scoping
• feature flags/entitlements

Never assume:

• “logged in with SSO” = “can access everything”

---

11) Support logout carefully

OIDC logout is messy in practice.

You may need:

• local session logout
• optional OIDC end-session endpoint
• front-channel/back-channel logout if provider supports it

Minimum viable:

• clear your session
• optionally redirect to IdP logout
• ensure user cannot keep accessing your app via stale session

---

12) Multi-tenant OIDC configuration

If each customer configures their own IdP, store something like:

tenant_id
issuer
client_id
client_secret_encrypted
redirect_uri
scopes
enforced_sso
allowed_email_domains

You may need:

• dynamic discovery from issuer URL
• metadata fetch from /.well-known/openid-configuration
• JWKS caching for token validation

---

13) Common pitfalls

• Trusting email without verifying email_verified
• Using sub without issuer
• Not checking state/nonce
• Accepting arbitrary redirect URIs
• Mixing up authentication and authorization
• Not handling users with multiple org memberships
• Assuming one IdP per company
• Making login dependent on exact email domain match
• Storing access tokens in localStorage for browser apps

---

14) Recommended architecture

For most B2B SaaS apps:

• Frontend
  • initiates login
  • uses session cookie
• Backend
  • handles OIDC callback
  • validates tokens
  • creates session
  • stores user/org mapping
• Database
  • users, orgs, memberships, identities
• Admin settings
  • per-tenant SSO configuration
• Provisioning
  • invites and/or SCIM

---

15) If you want the simplest robust implementation

Use this baseline:

• Authorization Code Flow + PKCE
• One session cookie for your app
• issuer + sub identity mapping
• organization memberships in your DB
• tenant-level SSO configuration
• invite + domain discovery for org selection
• role-based access control in your app

---

If you want, I can also provide:

1. a reference architecture diagram,
2. a database schema for B2B OIDC login, or
3. sample implementations in Node.js, Python, Go, or .NET.