--- description: "Enterprise SSO for LLMs: compare SAML vs OIDC, connect Okta, Entra ID, or Google Workspace to Bifrost, map groups to roles, and automate SCIM offboarding." title: "Enterprise SSO for LLMs: SAML vs OIDC Setup Guide" image: https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/enterprise-sso-for-llms-saml-vs-oidc-setup-guide-bifrost-1920x1080.png --- Try Bifrost Enterprise free for 14 days. [Request access](https://www.getmaxim.ai/#enterprise-trial) **TL;DR** - Enterprise SSO for LLMs authenticates people into the AI gateway through the corporate identity provider, so access to models, keys, and logs follows the directory. - Bifrost Enterprise implements SSO with OpenID Connect (Authorization Code with PKCE) and has setup guides for Okta, Microsoft Entra ID, Google Workspace, Keycloak, Zitadel, Auth0, and any standards-compliant OIDC provider. - IdP claims such as `groups` or `department` map to exactly one Bifrost role plus any number of teams, business units, and access profiles; a sign-in that resolves no role is refused. - Inbound SCIM 2.0 at `/scim/v2` pushes user creates, updates, and deactivations in real time; without SCIM, directory sync reconciles users every 24 hours by default. - Removing a user in Bifrost deletes their virtual keys, access profiles, and memberships, ends their sessions, and audit logs record admin changes. Enterprise SSO for LLMs means employees authenticate to the AI gateway with the same identity provider they use for every other internal system, so access to models, virtual keys, and request logs follows the corporate directory instead of shared admin passwords. [Bifrost](https://www.getmaxim.ai/bifrost), the [open-source AI gateway built for enterprise AI traffic](https://github.com/maximhq/bifrost) by Maxim AI, connects to Okta, Microsoft Entra ID, Google Workspace, and other identity providers through OpenID Connect. This guide compares SAML vs OIDC for an AI gateway, then covers enterprise SSO setup, group-to-role mapping, SCIM provisioning, offboarding, and audit logging in Bifrost. ## What Is Enterprise SSO for LLMs? Enterprise SSO for LLMs is a single sign-on setup in which the identity provider (IdP) authenticates every person who uses the AI gateway, and the gateway turns that verified identity into a role, team memberships, and policy. Users never get a separate gateway password, and offboarding in the IdP ends their AI access too. An AI gateway holds provider credentials, budgets, request logs, and MCP tool connections. Without enterprise SSO, teams fall back on one of three patterns: - **Shared admin credentials**, which make every configuration change anonymous. - **Manually created gateway users**, which drift from the directory as people move teams. - **Long-lived personal API keys**, which keep working after the person leaves. Enterprise SSO replaces all three with one source of truth. For the authorization side, see the primer on [LLM access control fundamentals](https://www.getmaxim.ai/articles/understanding-llm-access-control/). ## SAML vs OIDC: Which Protocol Fits an AI Gateway? SAML 2.0 and OpenID Connect both deliver single sign-on. SAML exchanges signed XML assertions through browser redirects and suits classic web apps. OIDC adds an identity layer to OAuth 2.0, issues signed JSON Web Tokens, and works for browsers, CLIs, and APIs alike, which is the client mix an AI gateway serves. [SAML 2.0 is an OASIS standard](https://www.oasis-open.org/standard/saml/) in which an identity provider issues XML assertions to a service provider. [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html), published by the OpenID Foundation, defines a JWT ID token and provider discovery on top of OAuth 2.0. | Criterion | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Standards body | OASIS | OpenID Foundation | | Token format | Signed XML assertion | Signed JSON Web Token | | Transport | Browser redirect and POST binding | OAuth 2.0 flows over HTTPS | | Key distribution | Certificates exchanged in metadata | Published JWKS endpoint | | CLIs, agents, SDKs | Awkward; built for browser sessions | Native bearer tokens | | Session refresh | IdP re-authentication | Refresh tokens (`offline_access`) | The deciding factor is the client mix: engineers use the dashboard, but also coding agents and SDKs that send bearer tokens on every request. OIDC covers both with one token format. That is why the [Bifrost AI gateway](https://www.getmaxim.ai/bifrost) implements enterprise SSO with OIDC and does not ship a native SAML 2.0 service provider. Okta, Entra ID, and Google Workspace issue OIDC alongside SAML, so a SAML-standardized organization registers one OIDC app for Bifrost in the same tenant and keeps its users, groups, and MFA policies. ## How Enterprise SSO Works in Bifrost [Bifrost Enterprise](https://www.getmaxim.ai/bifrost/enterprise) redirects unauthenticated users to the identity provider using the Authorization Code flow with PKCE, exchanges the code for access and refresh tokens, and validates the JWT against the provider's JWKS keys. It then maps the token's claims to a Bifrost user, role, and teams before the dashboard loads. The [user provisioning flow](https://docs.getbifrost.ai/enterprise/user-provisioning) has four stages after the redirect: 1. **Token exchange.** Bifrost requests `openid profile email offline_access`, stores tokens in an `HttpOnly` cookie and server session, and validates the signature. 2. **Identity extraction.** Configured claims identify the user and supply role and group values. 3. **Attribute mapping.** Rules translate claim values into roles, teams, business units, access profiles, and projects. 4. **Session refresh.** When a session expires, Bifrost refreshes it silently and re-applies the fresh claims. ![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-16.png) ***Figure 1: The identity provider decides who a person is; Bifrost turns that identity into a role, team memberships, and a policy before any model call.*** With OIDC or SCIM configured, open-source [basic dashboard authentication](https://docs.getbifrost.ai/quickstart/gateway/setting-up-auth) is no longer needed. SSO, SCIM, RBAC, and audit logs are Enterprise capabilities. ## Supported Identity Providers and Auth Proxies Bifrost Enterprise has OIDC setup guides for seven identity provider options, all configured from one screen under **Governance → User Provisioning**. The providers differ only in how the OAuth client and claims are created on the IdP side and which directory API Bifrost reads for bulk import and background sync. | Identity provider | Login | Directory sync source | SCIM guide | | --- | --- | --- | --- | | [Okta](https://docs.getbifrost.ai/enterprise/setting-up-okta/oidc) | OIDC, Org or Custom Authorization Server | API token | Yes | | [Microsoft Entra ID](https://docs.getbifrost.ai/enterprise/setting-up-entra/oidc) | OIDC, app roles, group claims | Microsoft Graph permissions | Yes | | [Google Workspace](https://docs.getbifrost.ai/enterprise/setting-up-google-workspace) | OAuth / OIDC | Service account, domain-wide delegation | Yes | | [Keycloak](https://docs.getbifrost.ai/enterprise/setting-up-keycloak/oidc) | OIDC (reads the access token) | Admin REST API | Not documented | | Zitadel | OIDC, project-scoped roles | Service account | Not documented | | Auth0 | OIDC with Post Login Actions | Optional M2M app | Not documented | | [Generic OIDC](https://docs.getbifrost.ai/enterprise/setting-up-generic-oidc/oidc) | Any compliant provider | Provider dependent | Yes | Bifrost also accepts [identity-aware proxies](https://docs.getbifrost.ai/enterprise/auth-proxy/generic-proxy) such as Cloudflare Access and AWS ALB that inject a signed JWT header. The proxy must be the only network path to the gateway, because a request without the header falls back to normal IdP login. ## OIDC SSO Setup Walkthrough: Okta, Entra ID, and Google Workspace OIDC SSO setup takes two steps in the identity provider and three in Bifrost: create a web OIDC application with the Bifrost callback URL, add a groups claim and assign users, then connect the provider, map claims, and enable it. The walkthrough uses Okta; Entra ID and Google Workspace differ only in the provider-side screens. ![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-17.png) ***Figure 2: Two steps happen in the IdP and three in Bifrost; SCIM is an add-on that replaces background sync with real-time push.*** ### Step 1: Create the OIDC application In the Okta admin console, create an app integration with **OIDC – OpenID Connect** and **Web Application**. Enable the **Authorization Code** grant only and set the redirect URI to `https:///login`. Add `https:///workspace/scim/oauth-discover-callback` as a second redirect URI to enable claim discovery. ### Step 2: Add a groups claim and assign users On the **Sign On** tab, add a `groups` claim with value type **Groups** and a filter such as the regex `bifrost-.*`. Profile attributes added here, such as `department`, become available for mapping. Assign people or groups to the app, since only assigned users can authenticate, then copy the client ID, client secret, and issuer URL. ### Step 3: Connect the provider in Bifrost Under **Governance → User Provisioning**, choose Okta, enter the issuer URL, client ID, and secret, and click **Verify & Next**. An optional Okta API token enables bulk import and directory sync. The same settings can live in `config.json`: ```json { "scim_config": { "enabled": true, "provider": "okta", "config": { "issuerUrl": "", "clientId": "env.OKTA_CLIENT_ID", "clientSecret": "env.OKTA_CLIENT_SECRET", "attributeRoleMappings": [ { "attribute": "groups", "value": "bifrost-admins", "role": "admin" }, { "attribute": "groups", "value": "bifrost-engineers", "role": "developer" } ], "attributeTeamMappings": [ { "attribute": "groups", "value": "bifrost-platform", "team": "Platform" } ] } } } ``` ### Step 4: Discover and map claims Click **Discover Claims** to list the exact claims the IdP sends, without creating a session. Map at least one group to the Admin role before anyone signs in: Bifrost has no default role, not even for the first user. ### Step 5: Enable and test Click **Enable**, restart Bifrost, and test in an incognito window so a misconfiguration cannot lock out the current session. **Entra ID.** Register the app with the same two redirect URIs, copy the tenant and client IDs, create a client secret, optionally define `admin`, `developer`, and `viewer` app roles, add a groups claim, and set **Assignment required** to **Yes**. **Google Workspace.** Configure the OAuth consent screen, create a web OAuth client, and optionally add a service account with domain-wide delegation for directory sync. The [Okta SSO walkthrough](https://docs.getbifrost.ai/enterprise/setting-up-okta/oidc) covers every screen. ## Mapping IdP Groups and Claims to Roles, Teams, and Access Profiles Bifrost converts IdP claims into authorization with mapping rules of the form `{ attribute, value, target }`. Role rules produce exactly one role per user, while team, business unit, access profile, and project rules all apply when they match. Claim values can be strings, arrays, or nested paths such as `realm_access.roles`. ![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-18.png) ***Figure 3: A user gets exactly one role but can match many teams and access profiles; a sign-in that resolves no role is refused.*** The rules that matter most in production: - **Role resolution.** `roleResolutionStrategy` picks the role with the most permissions ( `highestPermissionCount`, the default) or the first matching rule ( `order`). - **No default role.** A sign-in that matches no role rule is refused, never deletes an account, and triggers a **Sign-in refused** notification to provisioning admins. - **Wildcards.** A team value of uses the claim value as the team name, and `${*}` extracts a substring. Teams named by a rule are created on first use. - **Missing is not removed.** If a refreshed token omits an attribute, Bifrost keeps the last value; only a present, non-matching attribute removes a membership. Roles come from [role-based access control](https://docs.getbifrost.ai/enterprise/rbac): Admin (42 permissions), Developer (27), Viewer (14), plus custom roles such as an Auditor. Each role also carries a [data access control](https://docs.getbifrost.ai/enterprise/data-access-control) scope that decides which records its holders see. Access profile mappings attach provider, model, and budget policies; that policy layer is covered in the guide to [access profiles, RBAC, and DAC](https://www.getmaxim.ai/articles/ai-governance-guide-access-profiles-rbac-dac/). ## SCIM Provisioning: Real-Time Onboarding and Updates SCIM provisioning lets the identity provider push user and group changes to Bifrost as they happen, instead of waiting for a sign-in or scheduled sync. Bifrost exposes an inbound SCIM 2.0 endpoint at `/scim/v2`, authenticated with a per-provider bearer token, and re-evaluates every mapping on each create, replace, or patch. SCIM is defined in IETF [RFC 7644](https://datatracker.ietf.org/doc/html/rfc7644). SSO authenticates a person at sign-in; SCIM provisions and deprovisions accounts whether or not the person ever signs in. Enabling [SCIM with Okta](https://docs.getbifrost.ai/enterprise/setting-up-okta/scim) takes three moves: 1. In Bifrost, toggle **Enable SCIM Provisioning** on the provider and copy the endpoint URL and provisioning token, which is shown once. 2. In Okta, add the **SCIM 2.0 Test App (Header Auth)** as a separate app, enter the URL and token, and enable **Create Users**, **Update User Attributes**, and **Deactivate Users**. 3. Assign users and **Push Groups** that drive team mappings, setting `claimScimAttributes` to `"attributeType": "group"` for the `groups` claim. The `claimsSyncMode` setting decides who owns user data once SCIM is on: | Mode | Who decides access | Unprovisioned user signs in | Directory sync | | --- | --- | --- | --- | | SCIM off | Sign-in claims plus directory sync | Created just in time | Every `bulkSyncInterval` (default `24h`) | | SCIM on, `both` | Claims and SCIM; last write wins | Created just in time | Off | | SCIM on, `scim` | SCIM alone | Refused until pushed | Off | Choose `scim` for one source of truth; in `both` mode the SCIM payload and sign-in token must carry the same attributes. SCIM user changes reach every node of a [clustered deployment](https://docs.getbifrost.ai/enterprise/clustering) before the response returns. ## Offboarding and Session Lifecycle Offboarding in Bifrost follows the identity provider. Depending on the sync mode, a SCIM deactivation or delete, a failed session refresh for a user the IdP reports inactive, or a directory sync that no longer finds the user removes that user, along with their keys, policies, and sessions. ![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-19.png) ***Figure 4: Which channel removes the user depends on the sync mode, but the result is the same: keys, profiles, memberships, and sessions are gone.*** Removal deletes the user's virtual keys, access profiles, memberships, and personal budget, and ends their dashboard and desktop-agent sessions. A SCIM deactivation (`active: false`) keeps the stored profile for reactivation; a SCIM `DELETE` clears it. A failed refresh alone only signs the user out. Under the [identity sync rules](https://docs.getbifrost.ai/enterprise/how-identity-sync-works), roles always follow the IdP. When SCIM is on, background sync is off, so the IdP's SCIM connector must have deprovisioning enabled. ## Audit Logs for Admin Activity [Audit logs](https://docs.getbifrost.ai/enterprise/audit-logs) in Bifrost Enterprise record administrative activity, including sign-ins and role and membership changes, so security teams can see who changed what, when, and on which resource. Entries can be HMAC-signed, retained for a set period, exported to a SIEM, and archived to object storage. ```json { "audit_logs": { "hmac_key": "env.AUDIT_HMAC_KEY", "retention_days": 365 } } ``` Each entry records the action, outcome, initiator, target, request path, and client IP. For compliance reviews: - **Signing.** An `hmac_key` of at least 32 bytes makes events verifiable. - **Export.** Holders of `AuditLogs:Download` export JSON, JSON Lines, or Syslog (RFC 5424). - **Archival.** An `object_storage` block mirrors events to S3 or GCS in manifest-committed windows. - **Privacy.** `omit_ip_addresses` keeps the trail without client IPs. Model traffic lives in request logs instead; see [audit trail controls for LLM traffic](https://www.getmaxim.ai/articles/ai-audit-trail-controls-and-audit-logs-for-llm-traffic/). ## Where SSO Ends: Model Access, Budgets, and API Keys Enterprise SSO establishes who a person is and which role they hold. Which models they can call, how much they can spend, and how applications authenticate are separate controls built on that identity, each covered in depth elsewhere. - **Model access** comes from access profiles on a user's role, teams, or IdP attributes; see [governing AI traffic with RBAC, SSO, and virtual keys](https://www.getmaxim.ai/articles/llm-access-control-rbac-sso-and-virtual-keys-for-ai-traffic/). - **Budgets** charge each request to the user's profile and every team and business unit above them; see [budgets and limits](https://docs.getbifrost.ai/features/governance/budget-and-limits). - **Applications** authenticate with [virtual keys](https://docs.getbifrost.ai/features/governance/virtual-keys) rather than user tokens. Inference routes also accept an IdP access token in `Authorization: Bearer`, so people can call models as themselves; with `enforce_auth_on_inference` on, an expired token gets a `401`. For coding agents, see [securing Claude Code with SSO and audit logs](https://www.getmaxim.ai/articles/securing-claude-code-in-production-sso-audit-logs-and-pii-guardrails-for-engineering-teams/). ## Frequently Asked Questions ### Which is better, SAML or OpenID? For an AI gateway, OpenID Connect is the better fit. It issues JSON Web Tokens that work for browser sessions and for bearer-token calls from CLIs, SDKs, and coding agents, with signatures validated through a published JWKS endpoint. SAML 2.0 remains common for legacy web applications, and most enterprise identity providers support both protocols. ### Is OIDC based on SAML? No: OpenID Connect is built on OAuth 2.0, not SAML. The OpenID Foundation defines OIDC as an identity layer adding an ID token, a userinfo endpoint, and discovery to OAuth 2.0 flows. SAML 2.0 is a separate OASIS standard using XML assertions. Both solve single sign-on with different token formats and transports. ### Is SAML obsolete? SAML is not obsolete, but new integrations increasingly choose OIDC. SAML 2.0 still secures many enterprise web applications, and identity providers such as Okta and Microsoft Entra ID continue to support it. For API-heavy systems like an AI gateway, OIDC is more practical because its tokens travel naturally on requests from non-browser clients. ### What is the difference between SCIM and SSO? SSO authenticates a user at sign-in; SCIM provisions and deprovisions accounts between systems. With SSO alone, Bifrost creates a user on first sign-in and learns about changes later. With [SCIM provisioning](https://docs.getbifrost.ai/enterprise/setting-up-generic-oidc/scim), the identity provider pushes creates, updates, and deactivations to `/scim/v2` in real time, including for people who never sign in. ### How to use Okta for SSO with an AI gateway? Create an Okta OIDC web application with the gateway's `/login` callback, add a `groups` claim, and assign the people who need access. In Bifrost, select Okta under User Provisioning, enter the issuer URL, client ID, and secret, map Okta groups to roles and teams, and enable the provider. An Okta SCIM app adds real-time provisioning. ### Is MFA required for SSO? SSO does not require MFA, but enterprise identity providers commonly enforce it at sign-in, and SSO carries that enforcement to every connected application. Because Bifrost delegates authentication to the IdP, MFA and conditional access policies configured in Okta, Entra ID, or Google Workspace apply to gateway sign-ins with no separate setup. ## Start Building with Bifrost Enterprise SSO turns an AI gateway into a governed system: the IdP decides who signs in, Bifrost maps identity to a role and policies, SCIM keeps accounts current, and audit logs record admin changes. The [Bifrost governance resources](https://www.getmaxim.ai/bifrost/resources/governance) cover the policy layer above identity. To see enterprise SSO, SCIM provisioning, and audit logging running against your own identity provider, [book a Bifrost demo](https://getmaxim.ai/bifrost/book-a-demo). ## Read next [![API Key Management for LLM Apps: How to Manage Client Access](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/how-to-enforce-ai-budgets-per-team-project-and-key-bifrost-1920x1080--1-.png) API key management for LLM applications means issuing every app, service, and environment its own revocable credential instead of sharing raw provider keys. This guide shows how to do it with Bifrost virtual keys, covering scoping, rate limits, rotation, revocation, and log attribution.](https://www.getmaxim.ai/articles/api-key-management-for-llm-applications/) [![Claude Agent SDK Through a Gateway: Routing, Budgets, MCP](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/claude-agent-sdk-through-a-gateway-routing-budgets-mcp-bifrost-1920x1080.png) The Claude Agent SDK packages Claude Code's agent loop, tools, and context management as a Python and TypeScript library. This guide shows how to route Claude Agent SDK traffic through Bifrost for provider routing and failover, per-tenant budgets, and governed MCP tool access.](https://www.getmaxim.ai/articles/claude-agent-sdk-through-a-gateway-routing-budgets-mcp/) [![How to Enforce AI Budgets Per Team, Project and Key](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/how-to-enforce-ai-budgets-per-team-project-and-key-bifrost-1920x1080.png) An AI budget is a hard spending ceiling enforced in the LLM request path, not a monthly report. This guide covers budget hierarchies, project mapping, reset windows, rate limits, exhausted-budget behavior, and a worked $10,000 example in Bifrost.](https://www.getmaxim.ai/articles/enforce-ai-budgets/) ## More in AI Gateway [![OpenClaw vs Hermes: Which Agent to Run and How to Control It](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/openclaw-vs-hermes-which-agent-to-run-and-how-to-control-it-bifrost-1920x1080.png) OpenClaw and Hermes Agent are open-source, self-hosted AI agents that run on your own hardware and reach you through chat apps. This openclaw vs hermes guide compares how each is built and secured, says which to run for which job, and shows how to cap its models, spend, and MCP tools.](https://www.getmaxim.ai/articles/openclaw-vs-hermes-which-agent-to-run-and-how-to-control-it/) [![AI Access Control: How to Restrict Model Access by Role and Team](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/ai-access-control-how-to-restrict-model-access-by-role-and-t-bifrost-1920x1080.png) AI access control decides which models, providers, and tools each team, role, or user may call. This guide shows how to build per-team model allowlists in Bifrost, with a worked example, the exact config fields, and what a denied request returns.](https://www.getmaxim.ai/articles/ai-access-control-by-role-and-team/) ```json { "@context": "https://schema.org", "@type": "Article", "publisher": { "@type": "Organization", "name": "Maxim Articles", "url": "https://www.getmaxim.ai/articles/", "logo": { "@type": "ImageObject", "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w256h256/2025/08/thumbnail.png", "width": 60, "height": 60 } }, "author": { "@type": "Person", "name": "Kamya Shah", "image": { "@type": "ImageObject", "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2025/09/WhatsApp-Image-2025-08-29-at-17.40.40-1.jpeg", "width": 1200, "height": 1600 }, "url": "https://www.getmaxim.ai/articles/author/kamya/", "sameAs": [] }, "headline": "Enterprise SSO for LLMs: SAML vs OIDC Setup Guide", "url": "https://www.getmaxim.ai/articles/enterprise-sso-for-llms/", "datePublished": "2026-10-20T21:57:00.000Z", "dateModified": "2026-10-23T22:01:09.000Z", "image": { "@type": "ImageObject", "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/enterprise-sso-for-llms-saml-vs-oidc-setup-guide-bifrost-1920x1080.png", "width": 1200, "height": 675 }, "keywords": "AI Gateway", "description": "Enterprise SSO for LLMs lets employees reach the AI gateway with their corporate identity, so roles, teams, and offboarding follow the directory. This guide compares SAML and OIDC, then walks through OIDC setup, claim mapping, SCIM provisioning, and audit logs in Bifrost.\n", "mainEntityOfPage": "https://www.getmaxim.ai/articles/enterprise-sso-for-llms/" } ```