How do we put LiteLLM admin sign-in behind our identity provider?
LiteLLM admin UI SSO works with Google, Microsoft Entra ID, Okta and generic OIDC providers, and the free tier covers up to five users. If your self-hosted proxy still signs administrators in with local credentials, you can move the admin UI to corporate sign-in without buying a license for a small admin group. Beyond five users, or once you need the governance features covered below, you will need an Enterprise license, so confirm the user count and feature list with LiteLLM before you commit to a design.
The work is harder than it looks because the admin UI is only one of several access paths. SSO controls who can sign in to the dashboard and manage keys, models and teams. It does not change how applications authenticate. Virtual keys continue to authenticate API calls, so a successful SSO migration leaves application traffic untouched and does nothing to retire the keys that already exist. Plan the two access paths as separate workstreams with separate owners, and document which identities are allowed to change routing, budgets and provider credentials.
Keep the master key as a break-glass credential. LITELLM_MASTER_KEY stays valid for administrative access even after SSO is working, which is useful when the identity provider is unavailable or misconfigured during an incident. Store it in a secret manager, restrict who can read it, define the procedure for using it, and log each use. Test the break-glass path before go-live so that the first time anyone uses it is not during an outage. Decide who holds it and how it is rotated after use.
Team assignment depends on claims your identity provider sends. Mapping users into LiteLLM teams with the right budgets and model access requires the group or role claims in the token to be consistent, populated and named the way the proxy expects. Ask your identity team which claims each provider will issue for the Google, Entra ID, Okta or OIDC application, who maintains the group membership, and what happens to a user who signs in without any matching group. Test with a few accounts from each group before you rely on the mapping for access decisions.
SCIM provisioning and JWT authentication with identity provider tokens are Enterprise features, so do not assume they are available on the free tier. SCIM is the route for lifecycle changes such as removing leavers, and JWT covers token-based access for services. Confirm with LiteLLM which of these you need, obtain the Enterprise edition terms in writing, and confirm how your identity provider's offboarding process will reach the proxy. Where SCIM is not in scope, define a manual review step for removing administrators and an owner for that review.
Which LiteLLM settings and identity pieces are involved?
SSO for the LiteLLM admin UI touches more than the sign-in button. The proxy database, the master key, the identity provider application, claim mapping and the Enterprise options each hold part of the access model, and a change in one can lock out or over-grant users in another.
Admin UI SSO configuration
The proxy's admin UI is configured with the sign-in provider settings: Google, Microsoft Entra ID (Azure AD), Okta or a generic OIDC provider. Confirm which provider type your identity platform maps to, which environment variables or config entries hold the client details, and how the proxy URL is set. Test sign-in with a non-administrator account before you disable any other login path.
PostgreSQL proxy database
The proxy database stores users, teams and the virtual keys that applications use. PostgreSQL is the primary supported store, and virtual keys require it, so SSO-linked users and team membership depend on it. Plan its backup, restore testing and access controls as part of the identity design, not as a separate infrastructure task.
LITELLM_MASTER_KEY as break-glass access
LITELLM_MASTER_KEY must start with sk- and grants full administrative access independent of SSO. Store it in a secret manager, limit who can read it, and document when it may be used. Test that an administrator can still reach the admin UI if the identity provider is unavailable, and confirm how the key is rotated after use.
Identity provider application and redirect URI
Each identity platform needs an application registration for the proxy, with a redirect URI that exactly matches the proxy's callback address for your environment. Confirm the exact callback path in the LiteLLM SSO documentation for your version, the client secret handling, and which users or groups are assigned to the application. A mismatched redirect URI is the most common sign-in failure.
Claim mapping for team assignment
Team assignment from identity provider claims decides which users land in which LiteLLM team, and therefore which budgets and model access apply. Decide which claim or group carries team membership, how it is named in your directory, and what happens to users with no matching claim. Review the mapping with the team owners before rollout, because wrong mappings grant access silently.
Enterprise options: JWT auth and SCIM
SSO for more than five users, JWT authentication with identity provider tokens, and SCIM provisioning require a LiteLLM Enterprise license. Confirm the current free-user limit and license terms with LiteLLM before design, and decide whether user lifecycle through SCIM is needed or whether manual onboarding is acceptable. Each option adds components to test and operate.
Which identity option fits our size and governance needs?
This table compares the identity options for signing in to the LiteLLM admin UI and shows where the free five-user SSO tier ends and Enterprise features begin. Read each row against your user count, how often people join and leave, and whether team access must follow identity provider groups. The main takeaway: with five or fewer users, a supported provider works on the free tier, but SCIM and JWT authentication require an Enterprise agreement.
| Option | When it fits | What it costs you operationally |
|---|---|---|
| Teams on Google Workspace with a small, stable admin group. | Sign-in setup is straightforward. Confirm how groups or domains map to LiteLLM teams before rollout. | |
| Microsoft Entra ID | Organizations already running Entra ID for Microsoft 365 or Azure access. | Your identity team registers the application and redirect URLs. Confirm which token claims LiteLLM reads for roles. |
| Okta | Organizations that standardize workforce sign-in on Okta. | Your identity team configures the app and claims. Confirm SCIM connector support with the vendor before planning provisioning. |
| Generic OIDC | Any compliant provider, including one you already run for internal applications. | Your team owns the discovery URL, client registration and claim mapping. Test sign-in, logout and each admin role. |
| Free tier and Enterprise SSO | Free up to five users from v1.76.0. Enterprise SSO is needed beyond that. | The free tier has no license cost for SSO at this size. Beyond five users, ask for Enterprise terms, support scope and any SLA in writing. |
| JWT authentication | Applications or pipelines that send identity provider tokens to the proxy. | Enterprise feature. Issuer, audience and claim rules must be built, tested and owned through upgrades. |
| Manual user management | Small user counts with infrequent joiner and leaver events. | Admins create, role and remove users in the UI. Offboarding gaps are likely unless a review cadence is set. |
| SCIM provisioning | Larger groups where joiners and leavers change often. | Enterprise feature. Plan sync scope, attribute mapping and failure alerts, then test deprovisioning end to end. |
| Team assignment from claims or admin UI | Teams that want group membership to drive model and key access. | Confirm with the vendor whether team membership can come from identity claims or must be set in the admin UI. Manual assignment drifts over time. |
How do we configure LiteLLM SSO step by step?
This sequence takes a self-hosted LiteLLM proxy from a reachable, database-backed deployment to Admin UI sign-in through your identity provider, with team mapping, group restriction and a documented emergency path. Each step closes with a check you can run before moving on.
Confirm the proxy and database are ready
Before any identity work, the platform team confirms that the LiteLLM proxy answers at its final external URL, the address users will bookmark and the identity provider will redirect to. Confirm that PostgreSQL is in place, since LiteLLM's production guidance names it as the primary supported database and virtual keys and the Admin UI depend on it. If more than one proxy instance runs, confirm Redis 7.0 or newer is available for shared state. Done means the health endpoint responds over the final hostname and the proxy starts with its database connection in place. Changing the URL later means updating the callback registration, so settle it here.
Register LiteLLM in the identity provider
An administrator in Okta, Microsoft Entra ID, Google or your generic OIDC provider creates an application for the LiteLLM Admin UI. The callback URL registered there must match the proxy's final external address and the callback path given in the LiteLLM Admin UI SSO documentation, exactly, including scheme and trailing characters. Record the client identifier and generate a client secret, but do not paste the secret into tickets or configuration files. Done means the application exists in the identity provider with the correct redirect, and the owner can list the assigned groups that will be used later for access control.
Load SSO settings from a secret manager
Set the SSO-related environment variables for the chosen provider using the exact variable names listed in the LiteLLM Admin UI SSO documentation, since names differ by provider and version. Source the client secret and the master key from your secret manager rather than from plain manifests, and inject them at runtime into each proxy pod or instance. LiteLLM's guidance is to keep LITELLM_MASTER_KEY, which must start with sk-, in a secret manager. Done means the proxy restarts cleanly, the secret values do not appear in container logs or the rendered configuration, and a configuration review finds no credentials in version control.
Test sign-in with one admin account
Use a single administrator account that belongs to the approved group to sign in to the Admin UI through the identity provider. Keep the test to one user first so that a misconfigured redirect or secret does not lock out the whole group. Confirm that the redirect returns to the proxy, that the session is established, and that the user lands on the Admin UI with the expected permissions. If sign-in fails, check the callback URL, client identifier and secret source before changing anything else. Done means one named administrator signs in and out successfully, and the attempt appears in the proxy logs without any secret values.
Confirm role and team mapping from claims
Verify how identity provider claims or groups map to LiteLLM roles and teams. Check which claim carries the group or role information for your provider, and confirm in the LiteLLM documentation whether your edition and version support claim-based team assignment in the way your design requires. Sign in with two or three test accounts from different groups and check that each lands with the intended role and team, and no broader access. Note the mapping rules in your configuration record. Done means each test account shows the expected role and team in the Admin UI, and any account without a mapped group gets no team access.
Restrict access to the approved user group
Limit Admin UI access to the approved identity provider group, so that a valid corporate account outside that group is refused. Apply the restriction in the identity provider assignment or in the LiteLLM configuration, whichever your design uses, and document which layer enforces it. Confirm the limit on the free tier: LiteLLM's documentation says SSO is free for up to five users from v1.76.0, and an Enterprise license is needed beyond that, so count the approved users against this before rollout. Done means a test account outside the group is denied, and the user count matches your licensing position.
Document the master key as emergency access
Keep the master key as a documented break-glass credential for the case where SSO or the identity provider is unavailable. Record where the key is stored in the secret manager, which roles can retrieve it, how retrieval is logged, and the procedure for using it and rotating it afterwards. Confirm that the emergency procedure has been reviewed by the people who would invoke it, and that it is tested in a non-production environment. Done means the runbook names the custodians, the storage location and the rotation steps, and the security owner has signed off on the access model.
How do identity claims assign users to LiteLLM teams?
Identity claims decide which people land in which LiteLLM team, and the mapping is the part of the integration most likely to go wrong. Signing in proves who a person is. Team placement depends on what the identity provider sends with the sign-in and how the gateway reads it. The exact claim mapping behavior varies by edition and release, so confirm it against the current LiteLLM SSO and Enterprise documentation and test it on the exact version you plan to run. Free SSO covers up to 5 users from v1.76.0. Beyond that, the claim and team handling you need will sit in the Enterprise edition, which should be confirmed before the design is final.
Keep two populations separate in the design. The first is who can sign in to the admin UI and what administrative role they hold. The second is who owns virtual keys, budgets and spend. A person who can open the dashboard is not automatically the owner of the keys that applications use, and applications authenticate with their keys rather than with a person's login. Decide early which groups receive administrative access, which groups become team members, and which people can see spend across teams. Write those three answers down, because each one maps to a different claim value and a different set of permissions in LiteLLM.
Agree a naming convention for identity provider groups before go-live. Group names in Okta, Microsoft Entra ID or Google should map one to one to LiteLLM team names under a documented rule, such as an environment prefix, a business unit and a role suffix. The convention is illustrative, but the principle is real: a consistent pattern makes mismatches visible in review. Renaming a group after go-live can break the mapping, and it can leave keys or spend history attached to a team that no longer receives members. Name one owner for the group list and require an approval step for any new group, so the platform team is not guessing at intent later.
Mismatches are a common cause of users landing in the wrong team. Typical causes include differences in case or prefix between the provider group and the expected value, nested groups that do not appear in the token, users who belong to several groups with conflicting team intent, and a default team applied when no claim matches. Offboarded users can also keep team membership if the sync is incomplete. Build a test account for each team and each admin role, include one account with no groups to confirm it is denied or placed where policy says, and repeat the tests after every identity provider change. Confirm with each provider how large group lists are returned in tokens, since truncated lists produce silent gaps.
Before you finalize the design, ask the vendor or check the docs for four things: which claim fields the chosen edition reads for team and role assignment, whether JWT-based or SCIM-based provisioning is needed and is available on your edition, how membership is removed when a user leaves a group, and what the audit trail records when a mapping changes. Put the answers in the written scope so the mapping rules, test cases and owners are agreed before anyone signs in with production accounts.
What drives SSO effort and how do we keep it down?
This table lists the decisions that change how much work LiteLLM SSO takes, from admin headcount against the free five-user limit to change control and compliance evidence. Read each row as a question to settle before scoping, with the right-hand column showing the usual way to contain it. The main takeaway is that most avoidable effort comes from unsettled identity design and unclear environment boundaries, not from the LiteLLM configuration itself.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Admin users relative to the five-user free limit | SSO is free for up to 5 users in the admin UI, and an Enterprise license is needed beyond that. Counting admin users early decides whether licensing is part of the scope. | Confirm the exact count of people who need admin UI access, separate from application users who call the gateway with keys. Ask the vendor to confirm how users are counted for your version. |
| Number of identity providers or tenants | Each Okta org, Entra ID tenant, Google setup or generic OIDC provider needs its own registration, redirect URIs and testing. Multiple tenants multiply that work. | Standardize on one identity provider for admin sign-in where possible. Document each tenant that must remain and the owner who approves changes to it. |
| Group structure and claim quality | Team assignment depends on identity claims. Missing, inconsistent or renamed group claims lead to users landing in the wrong teams or none at all. | Agree the group naming scheme and claim names before configuration. Test with a few representative accounts in each group and record the claims received. |
| Whether SCIM provisioning is required | SCIM is an Enterprise feature. If user and group lifecycle must be automated, the license scope, directory mapping and offboarding tests all grow. | Decide whether sign-in alone meets the need. If SCIM is required, confirm the Enterprise edition covers it and define who owns deprovisioning. |
| Environments (dev, staging, production) | Each environment needs its own redirect URIs, client secrets, callback URLs and test users. Shared registrations across environments cause failed sign-ins and risky cross-environment access. | Create separate app registrations per environment with a naming convention. Keep the same claim mapping in every environment so tests reflect production. |
| Change control on identity app registrations | Changes to client IDs, secrets, redirect URIs or claim rules can lock out every admin at once. Unreviewed edits are a common source of outages. | Route registration changes through the same approval process as other production changes. Store client secrets in a secret manager and record who changed what. |
| Compliance evidence requirements | Assessors often ask for proof of who can access the admin UI, how access is removed and how changes were approved. Evidence gathered late costs more than evidence collected as the system is built. | Agree the evidence list at the start, such as access reviews, configuration exports and change tickets. Confirm with your auditor which artifacts they accept. DeployOpen prepares evidence but does not issue audit opinions. |
How does SSO differ across single node, HA and Kubernetes deployments?
On a single proxy host, SSO is mostly a matter of one public hostname, one callback URL and one set of environment settings. The identity provider redirects the browser back to the proxy, and only one process has to agree with that redirect. Session state lives with that one instance, so there is little coordination to design.
What to check on a single node:
- One redirect URL: register the exact callback path for the public hostname users type into the browser, including the scheme and port.
- Hostname consistency: if the proxy sits behind a reverse proxy or TLS terminator, confirm the external hostname is what LiteLLM sees, not an internal address.
- Master key handling: keep LITELLM_MASTER_KEY, which must start with sk-, in a secret store or a protected environment file rather than in shell history or a plain config file.
- Database dependency: SSO admin sessions and user records depend on PostgreSQL, so confirm the database is reachable and backed up before testing sign-in.
- Test with real identity accounts: sign in with a standard user and an administrator account from your identity provider to confirm role mapping works.
Before go-live, confirm with your identity provider's administrators which redirect URIs they accept and whether a single-node restart clears or keeps sessions in your version.
When several proxy instances sit behind a load balancer, every instance must present the same externally visible identity. The identity provider sends the user back to one callback URL, but the browser may land on any instance, so each one needs identical configuration. Shared state also matters: LiteLLM's production guidance requires Redis 7.0 or newer once more than one proxy instance runs, for shared rate limits, router state and cache.
What changes with multiple instances:
- Identical callback URLs: every instance must use the same public base URL and the same redirect URI registered at the identity provider.
- Same configuration and secrets: all instances must share the same master key and SSO client settings, or sign-in will fail intermittently depending on which instance answers.
- Shared PostgreSQL and Redis: all instances should point at the same database and Redis deployment so sessions and limits behave the same way regardless of routing.
- Load balancer hostname: the redirect URL must match the hostname the load balancer exposes to users, not the address of any single instance.
- Sticky sessions are a decision: confirm with the LiteLLM documentation for your version whether sticky sessions are needed, and do not assume they are.
Before go-live, test sign-in and sign-out repeatedly through the load balancer and confirm each request succeeds regardless of which instance serves it.
On Kubernetes, the proxy usually runs as a Deployment with several pods, and the public hostname is handled by an Ingress or gateway. Pods are replaced during upgrades and scaling, so the SSO configuration must come from Kubernetes objects rather than from anything typed into a pod. LiteLLM recommends one Uvicorn worker per pod and scaling horizontally, which fits this model.
What Kubernetes changes:
- Secret delivery: store the master key, identity provider client secret and database credentials in Kubernetes Secrets or an external secret manager, and inject them as environment variables or mounted files into each pod.
- Ingress hostname: the redirect URL must match the hostname on the Ingress or load balancer that users reach, including TLS.
- ConfigMaps for settings: keep non-secret SSO settings, such as allowed domains and role claim names, in version-controlled ConfigMaps so every pod renders the same configuration.
- Rolling updates: confirm that existing sessions survive a rolling restart in your version, and test a pod replacement during sign-in.
- Shared backends: PostgreSQL and Redis run outside the pods or as managed services, so pods remain stateless.
Before go-live, confirm with your platform team how Secrets are rotated without redeploying, and confirm the external hostname in the redirect matches the Ingress host exactly.
How do we keep admin access and identity secrets safe?
Single sign-on moves who can sign in to the LiteLLM admin UI into your identity provider, but the admin surface still depends on a few high-value secrets and settings. The cards below cover where those secrets live, how the master key is used, how admin roles and network paths are narrowed, and how changes and departures are tracked.
Store client secrets in a secret manager
The OAuth or OIDC client secret that LiteLLM uses to talk to Okta, Entra ID, Google or a generic OIDC provider should never sit in a plain config file or a repository. Store it in your secret manager and inject it into the proxy at runtime. Confirm who can read that secret, how it is rotated, and whether rotation requires a proxy restart in your deployment. Enterprise secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk are the option to check if you need them.
Protect and limit the master key
LITELLM_MASTER_KEY grants full administrative control over the proxy, so it must be stored in a secret manager and kept out of logs and application code. The key must start with sk-. Use it only for break-glass work, such as recovering admin access when SSO is unavailable, and route day-to-day administration through named identities. Record each time the key is used and plan how you would rotate it after any suspected exposure.
Assign least-privilege admin roles
Signing in with SSO does not by itself limit what a user can do. Map identity provider groups to the smallest set of LiteLLM roles that fits each job, such as viewing spend versus managing keys or models. Organization and team RBAC is an Enterprise feature, so confirm which roles your edition supports before designing the mapping. Review the mapping whenever groups change in the identity provider.
Disable local fallback accounts
Before go-live, decide whether username and password accounts remain available alongside SSO. Every local account is a second sign-in path that sits outside your identity provider's MFA, lockout and offboarding controls. Where your policy allows, disable local fallback accounts once SSO is verified, and keep a documented, tested break-glass procedure instead. Confirm with LiteLLM's current documentation how the fallback behaves in your version.
Restrict admin UI network exposure
The admin UI should not be reachable from the public internet by default. Place the proxy behind your internal load balancer, VPN or zero-trust access layer, and confirm that the OIDC redirect URLs match only the hostnames you actually serve. Test the path from outside the approved network to confirm it fails. IP allowlisting for the admin surface is available in LiteLLM Enterprise, so check whether you need it in addition to network controls.
Log admin actions and offboard promptly
Audit logs for admin actions are an Enterprise feature, so confirm they cover key creation, budget changes, team assignments and role edits before relying on them for investigations. Offboarding is the other half: when someone leaves or changes role in the identity provider, their LiteLLM access should end through deprovisioning, which SCIM supports in the Enterprise edition. Test that a disabled identity cannot sign in and that its virtual keys are revoked or reassigned.
How do we test that SSO works and fails safely?
Test SSO before any business user depends on it, and test the failure paths as carefully as the happy path. For LiteLLM's admin UI, the core question is whether sign-in through Okta, Microsoft Entra ID, Google or a generic OIDC provider admits the right people, gives them the right access inside the proxy, and leaves a working emergency route when the identity provider is not available. Build the test plan from the identity provider groups you intend to map, not from a generic login check. Each approved group needs its own successful sign-in test with a named test account, and the expected result should state which admin UI role or team the user should land in. Next, test denial. Create or use an account that exists in the identity provider but belongs to no approved group, and confirm that LiteLLM does not grant admin access. Repeat the check for a user in a similar group that is not approved, because group name matching is where many misconfigurations hide. Then test role and team assignment directly. Where team membership is derived from identity provider claims, sign in as users from two different teams and confirm that each sees only the keys, budgets and models that belong to that team. Verify this in the admin UI and with the proxy's own key listing, not only by reading the configuration. Test lifecycle events. Disable a test user in the identity provider, wait for the session to expire, and confirm that the user cannot reach the admin UI or create new keys. Also confirm what happens to existing virtual keys that user created, because key ownership and access are separate questions. Confirm the proxy's session lifetime is set to a value your security team has approved, and document the observed behavior as a fact rather than an assumption. Whether revocation takes effect immediately or only at the next session refresh depends on your identity provider and proxy configuration, so confirm it in your own environment. Test emergency access and outages. The master key is the break-glass credential, and it must still work when SSO is misconfigured or the identity provider is unreachable. Verify that the master key authenticates to the admin API and UI in the test environment, that its storage location is restricted to named operators, and that using it is recorded in logs. Then simulate an identity provider outage by blocking the provider endpoint from the proxy network. Record what users see, whether existing sessions continue, and whether new sign-ins fail with a clear message rather than an error loop. Ask your vendor or support contact to confirm any behavior you cannot observe directly. Finally, keep the results as change evidence. Store each test case with its ID, the identity provider group or account used, the LiteLLM version under test, the date, the tester, the expected result, the actual result and any defect reference. Retain the record alongside the change ticket that enabled SSO, and rerun the full set after any upgrade, identity provider change or group rename. A repeatable record gives your auditors and change approvers evidence that access controls were verified, and it gives your operators a checklist for the next time sign-in breaks.
What should we monitor, back up and document after go-live?
This table lists the operational areas that keep LiteLLM SSO working after go-live, with the action for each and the reason it matters. Read it as a handover checklist: each row names something your team owns once the Admin UI sign-in path is in production. The main takeaway is that SSO failures are often quiet, so monitoring, backups and a tested break-glass path need to be in place before users depend on them.
| Area | What to do | Why |
|---|---|---|
| Sign-in failure monitoring | Log and alert on failed or repeated SSO callbacks, token validation errors and redirect mismatches from the proxy, and review them with the identity provider's sign-in logs | Users locked out of the Admin UI usually show up as support tickets first, so proxy-side signals catch misconfiguration early |
| Identity app secret rotation dates | Record the expiry date of the OIDC client secret or certificate in the identity provider, set reminders well ahead, and confirm the new value is stored in your secret manager before the old one lapses | An expired client secret stops all Admin UI sign-in at once, and the fix depends on someone who can still reach the identity provider admin console |
| User and team list reviews | Review Admin UI users and team membership on a fixed schedule against the identity provider groups or claims that drive team assignment | Team assignment from claims can drift when group membership changes, leaving former staff or misassigned users with access to budgets and keys |
| Database backups including users and teams | Confirm PostgreSQL backups cover the user, team and key tables, test a restore to a non-production instance, and document who can run it | Restoring the database without its user and team records can break role mapping, so the restore must be verified, not assumed |
| Upgrade testing for SSO behavior | Before moving to a newer release within the supported minor versions, test sign-in, callback URLs, team assignment and role mapping in a staging instance connected to the same identity provider configuration | Sign-in behavior can change between releases, and LiteLLM supports only the four most recent stable minor versions, so upgrades cannot be postponed indefinitely |
| Break-glass access runbook | Keep a documented, tested method to reach the Admin UI when SSO is down, stored outside the SSO path, with named custodians and a log of each use | If the identity provider or SSO configuration fails, administrators need a controlled way back in without weakening normal access |
When does LiteLLM SSO require an Enterprise license?
SSO for the LiteLLM admin UI is free for up to five users from v1.76.0. Beyond five users, the deployment needs an Enterprise license. Count users before you design the sign-in model, because the threshold decides whether the admin UI can stay on the open-source tier or whether licensing belongs in the first budget conversation. Confirm the user count with the people who will sign in to the admin UI, not only with the teams who will call the gateway through virtual keys, since those callers do not need admin UI accounts.
Some identity features sit behind the Enterprise edition regardless of user count. SCIM, which provisions and deprovisions users from your identity provider, and JWT authentication, which accepts identity provider tokens directly for requests, are Enterprise features according to LiteLLM's enterprise documentation. If your plan depends on automatic offboarding through SCIM or on token-based access from an identity provider, treat the license as a requirement for that design, not as an optional extra. Without SCIM, you will need a manual process to disable admin accounts when people leave.
Licensing terms change between releases, so confirm current terms with LiteLLM before planning. Ask for the written terms that apply to the version you intend to deploy, the user threshold and how it is counted, which features are covered, and whether the terms cover self-hosted production use in your environment. Ask how support and the four-version support window apply to each edition, since those affect your upgrade plan.
The repository uses two licenses, and this matters for your legal review. Code outside the enterprise/ directory is under the MIT license, while content under enterprise/ is governed by the license in enterprise/LICENSE. Ask your legal or procurement team to review both files in the exact release you plan to run, and check whether any custom patches you intend to add touch the enterprise/ directory. Mixing enterprise code into a fork without reviewing that license can create obligations that your open-source plan did not account for.
Before you approve the design, record three decisions: the number of admin UI users, whether SCIM or JWT is required, and who in your organization signs the license terms. Put those answers in the implementation plan so that the identity provider configuration, the team assignment approach and the license request are scoped together. If the answers change later, such as when headcount grows past five admins, the design should already show which step triggers the license purchase.
What do buyers ask before bringing in help with LiteLLM SSO?
What drives the cost of LiteLLM SSO and identity integration work?
The cost follows the scope agreed in writing before work starts. The main drivers are the number of identity providers, the number of environments that need sign-in (for example, staging and production), how many teams map to identity provider groups, and whether SCIM or JWT authentication is in scope, since both require Enterprise. DeployOpen is paid for planning, configuration, testing, documentation and handover. LiteLLM Enterprise licensing is a separate cost, needed only beyond the free SSO limit of five users. DeployOpen is not a LiteLLM reseller, so confirm license terms directly with LiteLLM. Most of this work is one-time, while licenses, identity provider subscriptions and any support retainer recur. Ask for a quote that lists each component separately. DeployOpen does not publish prices, and a quote follows from the written scope.
How long does LiteLLM SSO integration usually take to deliver?
Duration depends on several drivers rather than a fixed number. The biggest variables are how quickly your identity provider administrator can register the application and configure claims or groups, how many group-to-team mappings need design decisions, and how many environments must be configured and tested. Change approval cycles and the availability of test users also affect the schedule. If the LiteLLM gateway is not yet deployed in the target environment, that deployment adds time to the plan. Fixed-scope engagements agree timelines in writing before work starts, so ask for a schedule that shows which steps depend on your staff, your identity provider team and your change board.
What must our team provide before SSO work starts on LiteLLM?
Most delays come from access and decisions that were not ready at kickoff. Plan to provide:
- Identity provider administrator access, or a named administrator who can register the application and set claims and groups.
- Group design decisions that map identity provider groups to LiteLLM teams and roles.
- Test users covering each role, including at least one user who should be denied access.
- Access to target environments, such as the Kubernetes cluster, the database and the secret manager that holds the master key.
- A named approver for change windows and a decision on the public hostname used for sign-in redirects.
Confirm each item with your security team before the scope is signed.
Can our own identity or platform team set up LiteLLM SSO without help?
Yes, a capable internal team can do this work, provided it has hands-on experience with OIDC configuration, identity provider group or claim mapping, and Kubernetes or the platform where the proxy runs. The effort is mostly configuration and testing, but the risk sits in the details: a misconfigured claim can place users in the wrong team, and an incorrect redirect setting can lock out administrators. Read the LiteLLM admin UI SSO documentation first, then estimate the time your staff can commit. A short scoping call can show whether your team needs outside review for the group design, the test plan or the outage procedure.
When does LiteLLM SSO require an Enterprise license?
SSO for the LiteLLM admin UI is free for up to five users from v1.76.0 onward. Beyond five users, an Enterprise license is needed. SCIM and JWT authentication with identity provider tokens are also Enterprise features, along with audit logs and organization and team RBAC. Confirm how LiteLLM counts users for licensing, since shared service accounts and former employees can change the count. Also confirm the current edition terms with LiteLLM, because editions and limits can change between releases. Your release must be v1.76.0 or later to rely on the free five-user limit.
How does SCIM differ from managing LiteLLM users by hand?
With manual management, administrators create users in the LiteLLM admin UI and assign teams themselves, so a departed employee keeps access until someone removes them. SCIM lets your identity provider create, update and deprovision LiteLLM users automatically as people join, change roles or leave. SCIM is an LiteLLM Enterprise feature, so it adds license cost and identity provider provisioning configuration to the work. Confirm which user attributes and group memberships sync in your LiteLLM version, and whether synced groups map to teams automatically or need a separate step. Test deprovisioning explicitly, because it is the control that matters most for offboarding.
What happens to LiteLLM access if the identity provider is down?
Confirm this behavior in LiteLLM's documentation and in your own staging environment before go-live, because it determines your outage plan. Test three things: whether administrators already signed in keep their sessions, whether new admin UI sign-ins fail, and whether API traffic using virtual keys depends on the identity provider at all. Plan a break-glass path that does not depend on the identity provider, such as the master key kept in a secret manager with a documented list of who may use it and when. Record the procedure, and rehearse it during a planned outage so the team knows the steps under pressure.
Which identity providers does LiteLLM support for admin UI sign-in?
The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID (Azure AD), Okta and generic OIDC providers. Your choice of provider affects how groups and claims are configured, how users are provisioned and how the redirect settings are set, so the design work differs between them. If your organization uses a different identity provider that speaks OIDC, confirm the claim names, group format and token settings with LiteLLM's admin UI SSO documentation and test them with real accounts before committing to a design.
Where are the official LiteLLM SSO and licensing references?
The official references for this topic are the LiteLLM admin UI SSO documentation, the Enterprise documentation, the virtual keys documentation and the production best practices guide. The links are listed below, and you should use them to confirm current configuration before you commit to a design. Treat these pages as the source of truth for provider setup steps, field names, team mapping and license terms. Documentation written for one release can drift from another, so the reviewer should record the LiteLLM version tested against each page. A design review that cites a page without a version number is hard to repeat when the next release arrives, and it is hard to defend during an audit.
Licensing needs its own check before anyone assumes that SSO and team features are open source. The BerriAI/litellm LICENSE file describes a dual arrangement: content under the enterprise/ directory uses the license in enterprise/LICENSE, and everything else is under the MIT license. Confirm which directories your deployed build includes and whether your configuration relies on any code paths in enterprise/. Legal and procurement should read the license files directly rather than relying on secondhand summaries, then record the result alongside the version reviewed. Ask your LiteLLM contact to confirm in writing how any Enterprise features you plan to use are licensed, so the decision does not depend on an informal answer.
The free SSO allowance is also tied to a specific release. The admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers. From v1.76.0, SSO is free for up to 5 users, and an Enterprise license is needed beyond that number. Confirm the current user count rule on the admin UI SSO page against the exact version your pilot runs, and check whether your planned user population stays within the limit or needs a license from day one. JWT authentication and SCIM sit in the Enterprise feature set, so review the Enterprise page for their terms before you design identity automation around them.
Use the production guide and the virtual keys documentation to check the dependencies that SSO and team access rely on. Virtual keys require a PostgreSQL database, and the production guide names PostgreSQL as the primary supported database. The master key, which must start with sk-, belongs in a secret manager rather than in a configuration file, and the guide also covers how the proxy should run at scale. Make the reference review a formal sign-off step with a named owner for each page, the date it was checked and the LiteLLM version it applies to. Ask the vendor to confirm in writing any point that remains ambiguous before go-live.
How DeployOpen works on LiteLLM SSO and identity integration
DeployOpen plans and builds LiteLLM admin UI sign-in against the identity provider your organization already runs, including Google, Microsoft Entra ID, Okta or a generic OIDC provider. Each engagement is fixed-scope, with the identity tests, configuration and handover agreed in writing before work starts, and support available as a retainer afterward.
How we scope
- Confirm which identity provider, tenant and admin groups will sign in to the LiteLLM admin UI.
- Count the admin users and decide whether the free five-user SSO tier covers the rollout or an Enterprise license is needed.
- Define which identity provider claims map to LiteLLM teams, and who approves that mapping.
- Record the written scope, deliverables and timeline before any configuration begins.
How we build
- Register LiteLLM as an OIDC or SAML application in the chosen identity provider with agreed redirect URLs.
- Store the client secret and master key in your secret manager rather than in plain configuration files.
- Configure the proxy callback settings and test sign-in, sign-out and session expiry with named test accounts.
- Verify that team assignment from claims lands users in the expected teams and that unauthorized users are refused.
How we hand over
- Document the identity provider setup, redirect URLs, claim-to-team mapping and every secret location.
- Provide a test script that repeats sign-in and team checks after any identity provider or LiteLLM upgrade.
- Walk the administrators through onboarding and offboarding steps for users and teams.
- Deliver the written configuration record so your identity and security teams can review it independently.
How we support
- Offer ongoing support, upgrades and re-testing of SSO as a retainer after go-live.
- Re-check sign-in after LiteLLM upgrades, staying within the supported minor versions your team chooses.
- Review whether JWT or SCIM options in the Enterprise edition are worth scoping as a later phase.
- Confirm with LiteLLM which Enterprise support terms apply to your license before relying on them.
