Open WebUI SSO and identity integration guide

Why Open WebUI SSO is the first access decision to get right

Open WebUI documents single sign-on through OIDC and LDAP, user and group provisioning through SCIM 2.0, role-based access with groups and authenticator-app MFA. For a team that has deployed Open WebUI, or is about to, the work is wiring these features to the organization's identity provider so that local accounts stop being created and maintained by hand. Access is the first decision to get right because every later choice, from which models a person can use to who can upload knowledge, depends on who the person is and which groups they belong to at sign-in. Settle the identity model before users are invited, not after a set of hand-made accounts has already accumulated.

The difficulty is that login, provisioning, group-to-role mapping and sign-out are separate mechanisms. Login proves who the user is. Provisioning decides whether an account exists and which groups it carries. Role mapping decides what those groups can do inside Open WebUI. Sign-out ends a browser session, which is a different event from ending access. A setup can pass a login test and still leave a departed employee with working access, or give a new hire the wrong role because a group claim never reached Open WebUI. Each mechanism needs its own test cases, and a successful sign-in should never be treated as proof that the other three work.

Sign-out needs particular attention in multi-replica deployments. The scaling guide states that without Redis, signing out does not revoke tokens, and those tokens stay valid until they expire, by default after 4 weeks. Redis is also required as shared state for sessions and websocket connections across replicas, so the decision affects the high availability design as well as SSO. Ask the security owner whether a 4-week token lifetime is acceptable for the users in scope, and whether a shorter lifetime or a documented revocation path is needed. Confirm the behavior in the scaling documentation for the version you run, and test it with a removed user before go-live.

Setting names change between releases. The latest release supplied for this page is v0.12.3, published on October 16, 2026, following v0.12.0 on October 10. Do not copy environment variable names from a blog post or an older install guide. Choose the version you will pin, read the features documentation for that version, and record the exact OIDC, LDAP, SCIM and group settings in your build notes. Ask your implementation partner to confirm the same settings in a test environment before any production user signs in, and repeat that check whenever you move to a new release.

Which identity components Open WebUI relies on

An SSO integration touches several separate components, and each one owns a different piece of the access decision. Read the cards as a map: the identity provider decides who a user is, while Open WebUI decides what that user can do and where session state lives.

OIDC login path

OIDC is the browser sign-in flow that hands authentication to your identity provider, which remains the authority for who a user is. Open WebUI receives the identity claims after sign-in and creates or matches a local account. Check which claims your provider issues, which claim maps to the Open WebUI user identifier and email, and how the client secret and redirect URLs are stored and rotated.

LDAP directory path

The LDAP path authenticates users against an existing directory rather than a browser redirect, so the directory is the source of truth for credentials and account status. Open WebUI uses the directory for sign-in and lookups, and local records hold only what the application needs. Confirm the bind account and its least-privilege scope, the search base and filter, and how disabled or removed directory accounts stop working in Open WebUI.

SCIM 2.0 user and group provisioning

SCIM 2.0 lets your identity provider create, update and deactivate users and push group membership to Open WebUI without manual steps. The identity provider owns the user and group records, and Open WebUI mirrors them. Verify which attributes sync, how deprovisioning is handled, and whether the provider's group names match the names your role mappings expect.

Role-based access control with groups

Groups carry role assignments and per-resource permissions for models, knowledge and tools inside Open WebUI. Open WebUI owns these authorization decisions, even when group membership arrives from the identity provider. Map each identity provider group to a deliberate role, decide whether group changes apply on next sign-in or immediately, and test that a user removed from a group loses access to restricted resources.

Authenticator-app MFA

Authenticator-app MFA is an Open WebUI feature for local sign-in, and it does not replace MFA enforced by your identity provider. Decide which layer is the authority for second factors before enabling it, since users may face two prompts or a bypass path. Confirm how enrollment and recovery work and which sign-in paths, including LDAP and OIDC, the second factor actually covers.

API keys

API keys let users and tools call Open WebUI outside the browser session, so they sit outside the identity provider's sign-in flow. Open WebUI issues and stores these keys, and the owner of each key is the user account it belongs to. Confirm who may create keys, whether keys are tied to a deprovisioned account, and how keys are revoked when an employee leaves.

Shared session state in PostgreSQL and Redis

In a multi-replica deployment, PostgreSQL holds the application database and Redis holds shared sessions, websocket connections and application state. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Confirm the Redis deployment, its persistence and failover behavior, and that sign-out and deprovisioning tests pass across every replica.

Which login and provisioning model fits your identity estate

This table compares the main login, provisioning, role mapping, MFA and recovery choices for Open WebUI, with the conditions where each one fits and the operational work it adds. Read each row as a decision: the right column names the cost you carry after go-live, which is usually the deciding factor. Most estates end up with OIDC, SCIM and a single recovery account, but the details depend on what your directory already does.

Decision	Best fit when	Operational cost to plan for
OIDC only	Your identity provider issues OIDC tokens and your users do not need direct directory binds from the application. Common for cloud-first estates.	Client registration, redirect URI and secret rotation are managed in the identity provider. You must confirm which claims Open WebUI reads for email, name and groups in your version.
LDAP only	Your users and groups live in a directory such as Active Directory and no OIDC front end exists. Common in on-premises estates.	A bind account must be created, scoped to read users and groups, and rotated. Directory outages or slow searches surface as failed logins, and password policy stays in the directory.
OIDC and LDAP together	You need OIDC for browser users and LDAP for a specific population, such as service accounts or a legacy group, that the identity provider cannot cover.	Two authentication paths mean two places to check when a user cannot sign in. Test which path a user matches and confirm that account linking cannot create duplicate identities.
SCIM 2.0 provisioning	Joiners, movers and leavers must be reflected in Open WebUI without waiting for the user to sign in, and access reviews depend on an accurate user list.	The identity provider's SCIM connector, its token and its attribute mapping need an owner. Confirm how deprovisioning maps to Open WebUI's account status and to session revocation.
Provisioning on first login only	The user population is small, access changes are rare, and you accept that an account persists until someone disables it in the application.	Leavers keep accounts and any valid tokens until expiry, by default 4 weeks, unless Redis-backed revocation is in place. This is a deprovisioning gap that an assessor will ask about.
Groups mapped to roles in the identity provider	Access decisions are already made in the directory and you want one place to change who can use which models or features.	Role mapping depends on group claims or SCIM group objects arriving in the expected format. Confirm the group claim name and test a user in each group before rollout.
Groups and roles defined inside Open WebUI	Application teams manage their own model access and the number of groups is small enough to maintain by hand.	Role definitions drift from the directory over time. Every group change must be made twice, and reviewers must check two systems to answer who has access.
MFA enforced at the identity provider	Your organization already requires MFA for applications and wants one policy, one enrollment flow and one audit trail for every sign-in.	Confirm that every sign-in path, including any LDAP path, passes through the enforced policy. Local accounts that skip the identity provider will bypass it.
Authenticator-app MFA inside Open WebUI	Your identity provider cannot enforce MFA for this application, or a small team needs MFA without changing the directory.	Enrollment, lost-device recovery and support requests are handled by your application administrators. This adds a second MFA policy to document and audit.
Keep a local administrator account for recovery	You need a way back in when the identity provider, the directory or the SSO configuration fails.	The recovery password must be stored in a vault, rotated and tested. Restrict its use, log every login and confirm that the account is excluded from automated deprovisioning.

How OIDC login and group claims reach Open WebUI roles

The sign-in path has three steps, and each one can fail independently. The user authenticates at your identity provider, not at Open WebUI. The identity provider then returns a signed set of claims about that user, including any group membership it knows about. Open WebUI reads those claims, matches the user to a local account, and applies the groups and roles that the claims map to. If any link in that chain is misconfigured, the user either lands with no access, lands with more access than intended, or gets a confusing error at sign-in. Plan the path end to end before you test it with real accounts.

The most common problem is the group claim itself. Confirm in the features documentation for your pinned release which claim Open WebUI reads for group membership, and whether it expects a list of group names or a list of identifiers. Then check what your identity provider actually emits. Many providers only include groups when the application is granted a specific scope, when a group claim mapper is configured, or when the group is a directory group the user is a direct member of rather than one inherited through nesting. Sign in with a test account, inspect the token the provider issues, and compare the group values character by character with the names you intend to map. Case differences, prefixes added by the provider, and display names versus internal identifiers are frequent causes of silent mismatches.

Decide now what happens when claims are incomplete. Ask the team to confirm, in the release documentation, whether a user with no group claim is created, denied, or placed in a default group, and whether that default is safe for your environment. Also confirm how a user whose groups match no configured role is treated. A safe default is usually least privilege: the account exists but cannot reach models, knowledge or tools until an administrator assigns it. Test three cases before go-live: a user with a valid group, a user with no group claim, and a user in a group you never mapped. Record the observed result for each. Those three results are the acceptance evidence for this part of the design.

Expect role assignments to change over time, so define who owns the mapping. Changes to identity provider group membership should flow to Open WebUI either at the next sign-in or through the provisioning path covered in the SCIM section, and you should verify which behavior your release uses. Ask your implementation partner or your own platform team to document the mapping table, the claim name, the expected value format and the default-role decision in one place. Store that document with your identity provider configuration so that the next person who edits either system can see the dependency. Ask for a quote that includes this claim testing as a named deliverable rather than an assumed part of setup.

Build order for Open WebUI SSO, step by step

This sequence connects Open WebUI to your identity provider so people sign in with corporate credentials, group membership sets their access, and people who leave lose access when the identity provider removes them. Each step closes with a check you can run yourself. Run the sequence in a non-production instance first, and record the outcome of each check before moving on.

Confirm the target release and identity protocol
Your platform team confirms which Open WebUI release you will deploy, whether your identity provider will use OIDC, LDAP or both, and which install method you support: Docker, Docker Compose, Kubernetes with Helm, or pip. Review the release notes on the project's GitHub releases page for changes to authentication settings. Ask the identity provider team whether it supports SCIM 2.0 and MFA for this application, because those answers shape steps six and seven. This step is done when the release, protocol, install method and provisioning support are written in the project record and approved by the security owner.
Register the application at the identity provider
The identity administrator creates an OIDC client for Open WebUI, or a bind account and search base if you use LDAP. The redirect URI must match the callback path documented for your release and the exact public address users will type into the browser. Restrict the application to the groups allowed to use the platform, and store the client secret in your secrets manager, not in shared documents. Check: a test sign-in against the registration returns a token, and the redirect URI in the registration matches the one Open WebUI reports when it starts.
Configure OIDC or LDAP in Open WebUI
The platform engineer sets the authentication variables for the chosen protocol in the deployment configuration. These include the issuer or directory address, client identifier and secret, and the attributes that supply email and display name. Disable open self-registration so only provisioned or invited accounts can enter. Keep one local administrator account for recovery and record where its credentials are held. Check: the logs show the provider loaded without configuration errors, and the login page offers the single sign-on option after a restart.
Test a single pilot login
Choose one non-administrator pilot user who belongs to an approved group. The pilot signs in from a clean browser session or a private window with no existing cookies. Confirm that the account is created on first login with the expected email address and name, and that it holds standard user rights only. Check: the pilot reaches the chat interface, and the administrator sees the account in the user list linked to the identity provider. Then repeat with a second user outside the approved group and confirm that access is refused.
Define groups and map them to roles
The platform owner decides which identity provider groups map to Open WebUI roles, such as user and administrator, and which groups control access to specific models and knowledge resources. Enter the mapping in the group settings, starting with the smallest possible set of administrator roles. Assign a named owner to each group, because group membership in the identity provider becomes the source of access. Check: a pilot user's record shows the expected group membership after sign-in, and that user can open only the models and resources granted to that group.
Enable SCIM 2.0 provisioning if supported
If the identity provider supports SCIM 2.0 for this application, the administrator creates the provisioning connection using the SCIM endpoint and token described in the Open WebUI features documentation for your release. Scope the connection to the groups in use and run an initial sync. Review what the sync creates, including users and group memberships. Check: a user assigned in the identity provider appears in Open WebUI without a manual sign-in, with group membership that matches the identity provider. If the provider cannot run SCIM, record that accounts are created at first login and that group changes apply at the next sign-in.
Enforce MFA at the identity provider
Enforce multifactor authentication through a sign-in or conditional access policy at the identity provider that applies to the Open WebUI application, so every sign-in path passes through it. If the identity provider cannot enforce MFA for this application, use the authenticator-app option in Open WebUI and confirm in the release documentation which sign-in paths it covers. Check: a pilot user is prompted for a second factor in a clean browser session, and an account with no enrolled factor is blocked or sent to enrollment.
Test deprovisioning and session revocation
Remove a test user from the approved group or disable the account at the identity provider, then confirm that the user loses access. Check whether the existing browser session is refused. The Open WebUI scaling guide notes that without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. If a revoked session still works, the deployment is missing the shared state store the guide describes. Record the outcome and the revocation path for each deployment mode before go-live.

What drives the effort and cost of an SSO integration

This table lists the factors that most change the scope of an Open WebUI SSO and identity integration, how each one moves effort, and what you can do before work starts to keep it contained. Use it to compare your environment against the drivers and to check that a quote reflects them. The main takeaway is that the role model and group count, agreed in writing early, usually matter more than the choice of protocol.

Driver	Why it changes effort or cost	How to keep it down
Identity sources	One OIDC provider is a single configuration. An LDAP directory plus a second IdP means two trust paths, two attribute models and more testing of login precedence.	Confirm which source is authoritative for each user population and avoid connecting a second source unless a use case requires it.
Groups and roles to map	Every group that must map to an Open WebUI role or permission adds design, configuration and test cases. Nested or overlapping groups add more.	Reduce the group count before integration and agree the role model in writing, including who may create groups and who approves changes.
SCIM 2.0 from the identity provider	If SCIM 2.0 user and group provisioning is available and attributes are clean, provisioning is largely configuration. If not, provisioning falls back to manual or scripted steps that recur.	Ask the identity team to confirm SCIM support, the attributes it sends and whether group membership is maintained in the directory, before quoting.
Attribute quality	Missing, duplicated or inconsistent email, name or group values cause mapping failures that surface only in testing or after go-live.	Audit the attributes Open WebUI will read with the identity owner and fix naming and uniqueness in the source system first.
Environments	Test, staging and production each need their own identity client registration, redirect URIs, secrets and test accounts, and each must be verified separately.	Agree the minimum environments in the scope and reuse the same configuration templates across them to limit repeated design work.
Replicas, Redis and PostgreSQL	Multiple replicas need Redis for sessions and websocket state, so token revocation on sign-out depends on it. Missing components add build and verification work before SSO itself.	Check whether PostgreSQL and Redis already exist and are supported by your platform team, and decide the replica count before the identity design starts.
Compliance evidence	Access reviews, joiner and leaver evidence and MFA enforcement records require logs and exports that must be designed, retained and sampled, which adds work and recurring effort.	Ask your assessor which evidence they expect, then define the export format and review cadence in the scope.
Ongoing changes	Group changes, identity provider updates and Open WebUI release upgrades that touch authentication recur after go-live and need regression testing each time.	Agree who owns group requests and identity provider changes, and whether the retainer covers auth-related upgrade testing.

How the identity setup changes by deployment model

On a single Open WebUI instance, session handling stays within one process, so the identity flow is the simplest of the four models. The main design question is recovery: if the identity provider, its certificate or the LDAP server fails, who can still sign in and administer the system?

Sign-out behavior: With one replica, sign-out is straightforward to test, and no shared session store is required for this model.
Database choice: SQLite is acceptable here only when the database file sits on locally attached SSD or NVMe storage, not on network storage.
Recovery path: Confirm an administrator account that can sign in without the identity provider, store its credentials securely, and test it before go-live.
Dependency records: Record the identity provider certificate expiry date and the LDAP server addresses so a failed dependency can be diagnosed quickly.

Before any users are moved over, take the identity provider offline in a test environment and confirm that the recovery account still works.

How to keep identity secrets and access paths safe

Single sign-on and directory sync make Open WebUI's sign-in path safer, but they also create new secrets, privileged accounts and side doors. The cards below cover the identity-specific controls to set and verify before users depend on the integration.

Store OIDC and LDAP secrets outside config files

The OIDC client secret and the LDAP bind password are credentials that can impersonate your integration. Keep them in your organization's secrets manager and inject them into the Open WebUI runtime at deploy time, rather than writing them into compose files, Helm values or environment files committed to source control. Check that they are absent from container images, shell history and logs, and confirm that rotation is possible without editing configuration by hand.

Scope the directory account to read only

Open WebUI needs to authenticate users and read group membership, not change the directory. Ask your directory team for a dedicated bind account with read-only rights limited to the search base that holds Open WebUI users and groups. Confirm that the account cannot reset passwords or modify group objects, and that its password expiry and rotation follow your service account policy.

Keep a documented break-glass administrator

If the identity provider is unreachable or misconfigured, administrators still need a way in. Maintain one break-glass administrator account with a strong, unique password stored in a sealed location and protected by MFA. Document who may use it, the approval step, and how each use is reviewed afterward. Test the procedure before go-live so the first use is not during an outage.

Limit which groups receive admin roles

Group-to-role mapping decides who can change models, connections, users and settings. Map only a small, named set of identity provider groups to Open WebUI administrator rights, and treat any change to those groups as a privileged change. Review the mapping after each provisioning run, because a broadly scoped directory group can silently grant administrator access to a large population.

Review API key issuance separately

API keys are created inside Open WebUI and are used outside the SSO sign-in flow, so disabling a user in the identity provider does not automatically stop their keys. Decide who may create API keys, review existing keys during onboarding, and define how keys are removed when someone leaves or changes role. Confirm this process with your security team before enabling key creation for general users.

Confirm open sign-up is disabled

If self-registration remains enabled, anyone who can reach the login page may create an account alongside your SSO users. Verify in the admin settings that open sign-up is turned off, and check that the setting survives redeployments and configuration changes. Test with an account outside your directory to confirm that sign-up is refused and that only federated or provisioned users can enter.

How to test SSO login, group roles and failure behavior

Test SSO before users depend on it. The test plan for Open WebUI should prove four things: that each supported sign-in path works, that only members of the allowed group get in, that every role tier receives the role its mapped group should grant, and that removing a person from the directory actually stops their access. Run these tests against a staging instance that uses the same identity provider tenant, the same OIDC or LDAP settings, and the same group claim names as production. A test that passes against a test tenant with different group names proves very little.

Start with the positive and negative login cases. For each supported path (OIDC, or LDAP if you use it), sign in with a test account from an allowed group and confirm access. Then sign in with a valid account that is outside the allowed group and confirm the rejection. Check the Open WebUI admin view to confirm that the rejected user was not created with a usable role. For role assignment, create one test user per role tier you intend to use, put each in its mapped group, and confirm the role shown in Open WebUI matches the group mapping on every tier. Record the group claim each user presented so that a mismatch can be traced to the identity provider or to the mapping configuration.

Deprovisioning needs its own test. Disable a test user in the directory, or remove them from the group that is provisioned through SCIM 2.0, then wait for the provisioning cycle to run and attempt a fresh sign-in. The user must not be able to sign in. Then run a sign-out test in a multi-replica setup. Sign in, sign out, and replay the old session token against a different replica. With Redis in place, the token should be rejected. The scaling guide states that without Redis, sign-out does not revoke tokens, so this test confirms that the Redis dependency is actually working rather than assumed. Confirm the token lifetime setting as well, since the default is documented as 4 weeks.

Failure tests show what your organization will experience when something breaks. Make the identity provider unreachable, for example by blocking the network path from the Open WebUI containers, and confirm that sign-in fails with a clear error and that no anonymous or fallback access is granted. Expire the directory bind password used for LDAP and confirm the same behavior. Remove a required claim from a test token, or change the claim name in a test identity, and confirm that the user is refused rather than admitted with a default role. These are the cases most likely to produce silent access, so each needs an explicit expected result written down before the test runs.

The safe failure state has three conditions. There is no anonymous access to chat, knowledge or model endpoints. Users see an error that tells them to contact support, without exposing configuration details. And the break-glass administrator path still works, so someone can repair the identity configuration. Confirm the break-glass account, its credential storage and its login route before the test begins, and confirm it is excluded from SSO-only enforcement. Record results for every test case, including the Open WebUI version, the identity provider configuration version and the date, and repeat the full plan for each release you upgrade to. Results from one release do not carry over to the next, so the record becomes your evidence that the integration behaves as expected after each change. Confirm with your identity team which claim names and group object types they will change in the coming quarters, because those changes are the most common cause of role drift.

What to monitor, document and maintain after SSO goes live

Once users sign in through the identity provider, the work shifts to keeping that path trustworthy: spotting failures early, keeping group mappings accurate, protecting credentials, and proving the access model still matches policy. The cards below cover the recurring tasks that connect these areas, and they are the items to agree on with the operations owner before cutover.

Monitor login and provisioning failures

Track failed OIDC or LDAP sign-ins, rejected MFA prompts and SCIM provisioning errors in the identity provider and in Open WebUI logs. A spike in failures often means an expired client secret, a changed redirect URI or a directory attribute that no longer matches the mapping. Set alerts on these signals so that a broken login path is found by the operations team before users report it.

Review group-to-role mappings

Group names in the directory drive which Open WebUI roles and resource permissions a user receives, so a renamed or reused group can silently grant access. Review the mapping on a fixed schedule with the owners of each group, and confirm that removed employees and retired groups no longer map to any role. Record each review with the reviewer's name and the date.

Rotate client secrets and bind credentials

The OIDC client secret and the LDAP bind account password are long-lived credentials that can reach the Open WebUI configuration. Agree a rotation interval with the security team, rotate both in the identity provider and in Open WebUI at the same change window, and confirm that the old secret is revoked. Store the new values in your secrets manager, not in configuration files or chat logs.

Back up configuration and PostgreSQL

Users, groups, role assignments and SSO settings live in the PostgreSQL database and in the deployment configuration, so a restore must recover both together. Test restores into a separate environment, not only backup jobs that report success. Confirm that encryption keys and environment variables are included in the backup scope, because a database restore without them can leave sessions or stored credentials unusable.

Re-test SSO on every version upgrade

Authentication settings and provisioning behavior can change between Open WebUI releases, and the project publishes releases often. Before upgrading production, run a scripted test in staging covering OIDC or LDAP sign-in, MFA enrollment, SCIM sync and role assignment for each group type. Include the rollback path, since a failed authentication change can lock out administrators as well as end users.

Document the access model for auditors

Keep a current record of who can sign in, how each group maps to a role, which resources each role can reach, and who approves changes. Auditors will ask for this model and for evidence that it was followed, such as change tickets, review sign-offs and provisioning logs. DeployOpen prepares these controls and evidence for compliance assessments, but independent auditors issue any attestation or certification.

Questions buyers ask before bringing in help with Open WebUI SSO

What drives the cost of an Open WebUI SSO integration?

Effort follows the number of identity sources, the protocol chosen, and how much group logic has to be designed. The main cost components are planning and design time, configuration and testing, work inside your identity provider or directory, and handover documentation. The initial integration, role and group mapping, and test cases are one-time work. Re-testing after upgrades, changes to identity provider groups, and any support retainer you choose are recurring. Costs rise when you need both OIDC and LDAP, when directory data is inconsistent, when many group-to-role mappings need sign-off, or when MFA enforcement must be checked on every login path. Ask for a quote that itemizes these components, marks each as fixed scope or time-and-materials, lists the client inputs it assumes, and names the environments it covers (test, staging and production). DeployOpen works from a written scope, so the quote should map to that scope line by line.

How long does an Open WebUI SSO integration take?

The schedule depends mainly on how quickly your team confirms identity provider settings, directory details and group decisions, and on how many test rounds are needed. Start with the protocol choice, since OIDC and LDAP each add their own configuration and test cycle. Next, the group design sets how much mapping and sign-off happens before go-live. Access also matters: a staging identity provider tenant and test accounts shorten the test cycle, while waiting for change approvals lengthens it. If SCIM 2.0 provisioning is in scope, allow time for attribute mapping and deprovisioning tests. Ask for the schedule as phases with named client dependencies, and ask which dates depend on your approvals. Treat any duration offered without a list of dependencies and assumptions as an estimate to be challenged, not a commitment.

What should appear in a quote for Open WebUI SSO work?

A useful quote states the scope in plain terms: which protocol or protocols are covered, which identity provider or directory is involved, whether SCIM 2.0 provisioning is included, and how groups map to Open WebUI roles. It should list the deliverables, such as configuration, test results, runbook and handover session, and say what is excluded, for example changes to the identity provider's own policy beyond the agreed settings. Look for the client responsibilities written out, including admin access, directory details, group decisions and test accounts. The quote should also state the assumptions behind the schedule, the acceptance criteria for go-live, and how change requests are priced if scope moves. Finally, check which costs are one-time and which recurring items, such as support or re-testing after upgrades, are offered as separate retainers.

Can our internal team set up Open WebUI SSO without a partner?

Often yes, if the team has identity engineers who already run OIDC or LDAP integrations, owns the Open WebUI deployment, and has time to test properly. Open WebUI documents SSO through OIDC and LDAP, so the starting material exists. The risk sits in the details: group-to-role mapping errors that grant too much or too little access, missed MFA paths, and incomplete deprovisioning. Multi-replica setups add a specific point to check. Without Redis as a shared state store, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. Before deciding, have your team write down the protocol, group design, test matrix and rollback steps. If several of those are unclear, a fixed-scope partner engagement or a short review can fill the gap.

What does the Open WebUI SSO work need from our identity team?

The work needs admin access to the identity provider, either to register the Open WebUI application for OIDC or to create a service account and read access for LDAP. It also needs directory details: the base distinguished names or tenant structure, the attributes used for identity and email, and how groups are structured. Your team must make the group design decisions, including which groups map to which Open WebUI roles, what the default role is for new users, and who approves changes. Test accounts are essential, ideally one per role plus users who should be denied access, in a staging environment that mirrors production. Name an owner for MFA policy and for sign-off. Agree on these inputs before the schedule starts, because waiting on them is the most common reason timelines slip.

Is SCIM 2.0 always available in Open WebUI?

Open WebUI's features documentation lists SCIM 2.0 user and group provisioning, but you should confirm availability for the exact version and edition you plan to run before you design around it. Check the release notes for your target version, since the project publishes releases often. Then confirm that your identity provider supports acting as a SCIM client for this application and which attributes it sends. Test deprovisioning as carefully as provisioning, because a removed user should lose access on the schedule your policy requires. Also plan for session behavior: if you run several replicas, token revocation depends on Redis, so a deprovisioned user may keep a valid session until tokens expire unless that state is shared. Ask the vendor or your partner to confirm each of these points in writing.

Do we need an Open WebUI enterprise license for SSO?

The published license documentation ties the enterprise license to white-labeling, custom branding and dedicated support options, and it does not present SSO as a feature of that license. The separate branding clause matters more for many teams: the Open WebUI License forbids altering or removing branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. So if you plan to change branding for a larger user base, the enterprise license becomes relevant regardless of SSO. Pricing is not published and is quoted after you contact enterprise sales with an expected seat count. Confirm with Open WebUI enterprise sales, in writing, whether any SSO capability you need depends on the license, and keep that answer with your project records.

How DeployOpen scopes, builds and hands over Open WebUI identity work

DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure. For Open WebUI SSO and identity integration, we agree a written scope first, build the OIDC or LDAP login, SCIM 2.0 provisioning, group-to-role mapping and MFA in your environment, then hand over the configuration, runbooks and test evidence your team needs to operate it.

How we scope

The written scope names the identity provider, whether OIDC, LDAP or both, and the login paths that must work.
It records which user and group attributes come from the directory and which Open WebUI roles each group maps to.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before build work starts.

How we build

We configure the chosen SSO protocol and SCIM 2.0 provisioning against a staging Open WebUI instance first.
We test sign-in, sign-out, group changes and deprovisioning, including confirming that token revocation behaves as designed.
Where multiple replicas are in scope, we verify shared Redis session state, since tokens otherwise remain valid until expiry.

How we hand over

Your team receives the configuration as documented in the agreed deliverables, including identity provider settings and group mappings.
Runbooks cover adding users and groups, rotating client secrets, adjusting MFA enforcement and handling offboarding.
Test results and the change record are delivered so your security and compliance teams can review the identity controls.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
Support can cover re-checking identity settings when Open WebUI releases change authentication behavior.
Ask in your quote which support hours, response paths and upgrade testing the retainer includes.