How do I set up OIDC for enterprise login?

Setting up OIDC (OpenID Connect) for enterprise login usually means configuring your app as an OIDC client and your identity provider (IdP) as the place that handles authentication. Here’s the standard setup.

1) Choose your identity provider

Common enterprise IdPs:

• Microsoft Entra ID (Azure AD)
• Okta
• Google Workspace
• Ping Identity
• Auth0 (often used as broker)

2) Register your application in the IdP

In the IdP admin console, create an app / client and note:

• Client ID
• Client Secret (for confidential/server-side apps)
• Issuer URL or Authority
• Discovery URL (often https://իդp/.well-known/openid-configuration)
• Allowed redirect/callback URIs
• Allowed logout redirect URIs if supported

3) Use the OIDC Authorization Code flow

For enterprise login, the recommended flow is:

• User clicks “Sign in”
• Redirect to IdP authorization endpoint
• User authenticates at IdP
• IdP redirects back to your app with an authorization code
• Your backend exchanges the code for tokens:
  • ID token (who the user is)
  • Access token (to call APIs, if needed)
  • Refresh token (optional, if enabled)

For browser-based apps, use:

• Authorization Code Flow + PKCE

4) Configure scopes

Typical scopes:

• openid (required)
• profile
• email
• optionally offline_access for refresh tokens

Example authorization request:

GET /authorize?
  client_id=YOUR_CLIENT_ID&
  response_type=code&
  scope=openid%20profile%20email&
  redirect_uri=https%3A%2F%2Fyourapp.com%2Fcallback&
  state=RANDOM_STATE&
  nonce=RANDOM_NONCE&
  code_challenge=PKCE_CHALLENGE&
  code_challenge_method=S256

5) Validate the tokens

On your backend, verify:

• Signature using the IdP’s JWKS public keys
• Issuer (iss)
• Audience (aud)
• Expiration (exp)
• Nonce in the ID token for browser flows

Never trust an ID token without validation.

6) Map enterprise users to app users

Decide how you identify users:

• Use stable claims like:
  • sub (subject, unique per issuer)
  • email
  • preferred_username
• If supporting multiple enterprise tenants, store:
  • issuer + sub as the unique key

7) Enforce access control

Common enterprise checks:

• Allow only specific domains (@company.com)
• Allow only specific groups/roles
• Allow only specific tenant IDs
• Use group/role claims from the IdP if available

8) Set up logout

Implement:

• App session logout
• Optional OIDC end-session logout with IdP
• Clear local cookies/session
• Redirect to post-logout URL if supported

9) Use secure session handling

Best practices:

• Keep tokens server-side if possible
• Use HttpOnly, Secure, SameSite cookies for sessions
• Rotate refresh tokens if supported
• Don’t store tokens in localStorage for sensitive enterprise apps

10) Test with a non-production tenant first

Check:

• Login redirect works
• Token validation works
• Group/role claims appear as expected
• Logout behaves correctly
• MFA / conditional access policies don’t break the flow

---

Minimal implementation checklist

You need:

• IdP app registration
• Redirect URI configured
• Authorization Code + PKCE
• Token validation
• Session creation in your app
• Logout handling
• User/role mapping

---

If you want, I can give you:

1. a vendor-specific setup for Azure AD / Okta / Google, or
2. a code example in Node.js, Python, Java, or .NET.