Open WebUI SCIM user provisioning

Open WebUI SCIM user provisioning: when a shared deployment needs it

SCIM 2.0 provisioning from Okta, Entra ID or Google Workspace keeps Open WebUI users and groups in step with your company directory, so accounts are created, changed and removed when the directory changes instead of by hand. The Open WebUI features documentation lists SCIM 2.0 user and group provisioning alongside OIDC and LDAP sign-in, which makes it a separate concern: the identity provider decides who can sign in, while SCIM decides which accounts and groups exist inside Open WebUI. If you run a shared deployment as an IT or platform lead, the questions are usually how quickly a leaver loses access and whether you can show who held access to which models at a given date.

Teams usually need provisioning when three conditions meet. First, joiner, mover and leaver volume is high enough that manual account work causes delays or errors, especially when people change departments and their model access should change with them. Second, access is organized by group. If you grant model, knowledge and tool permissions to groups in Open WebUI, group membership must follow the directory or permissions will drift from what your policy says. Third, auditors or internal reviewers expect a traceable record of who was provisioned, when, and through which group. A small team with a handful of users and one model may manage well with manual accounts, but the same deployment becomes hard to govern once several departments depend on it.

Deprovisioning deserves the closest review before you commit. The scaling documentation notes that without Redis, signing out does not revoke tokens, which then stay valid until they expire, by default after 4 weeks. A removed directory account could therefore keep working in Open WebUI for that window. Ask your team how removal reaches active sessions in your topology, whether a disabled user loses access immediately, and test the path with a dummy account before go-live. Also confirm which SCIM user and group operations your Open WebUI release supports, because the documentation names the capability without detailing every operation.

Check licensing and version early. Under the Open WebUI License, deployments above 50 users in any rolling 30-day period must keep Open WebUI branding intact unless the operator holds an enterprise license or written contributor permission. Enterprise licenses are quoted after contacting sales with an expected seat count, so ask the vendor whether SCIM is included at your tier. Confirm the release you will run as well; the current release on the project's GitHub releases page is v0.12.3, published October 16, 2026. Decide early whether provisioning belongs in this rollout or a later phase, because the identity provider application, the group design and the permission model must exist before sync can do useful work.

Which identity provider and sign-in pairings fit your deployment

This table compares Okta, Entra ID and Google Workspace against the questions you must answer before wiring SCIM 2.0 into Open WebUI. Read each row as a confirmation item for your own tenant, since connector availability, pushable group types and administrative roles depend on your licenses and configuration. The main takeaway is that sign-in and provisioning can be set up separately, so decide early which application owns each side.

Decision factor	Okta	Microsoft Entra ID	Google Workspace
SCIM connector for your tenant	Confirm that SCIM provisioning is available for your Okta edition and that it attaches to the Open WebUI app integration.	Confirm that the provisioning connector and its SCIM endpoint are available under your tenant license and setup path.	Confirm that your Google Workspace edition supports the SCIM connector you plan to use with Open WebUI.
Group object types that can be pushed	Confirm which group types the app integration sends and whether membership changes flow with user updates.	Confirm which security and Microsoft 365 group types provisioning sends, and how nested group membership is handled.	Confirm whether Google groups can be sent as group objects and how membership changes are delivered.
Sign-in and provisioning on one application	Confirm whether OIDC sign-in and SCIM provisioning share one app integration or need two, and how each is assigned.	Confirm whether the sign-in registration and the provisioning configuration sit on one enterprise application or separate ones.	Confirm whether SSO and provisioning are configured together or as separate steps for your Google setup.
Sign-in option (OIDC or LDAP)	Open WebUI documents OIDC and LDAP for sign-in. Confirm which option your Okta setup exposes to Open WebUI.	Open WebUI documents OIDC and LDAP for sign-in. Confirm the option your Entra ID setup supports for your deployment.	Open WebUI documents OIDC and LDAP for sign-in. Confirm which option your Google setup supports for your deployment.
Who administers the identity provider side	Confirm which Okta administrator role owns the app, group assignments and provisioning settings.	Confirm which Entra role owns the enterprise application, provisioning settings and group scope.	Confirm which Google super admin or delegated admin manages the app and the group sync.
Who administers the Open WebUI side	Your platform team owns the SCIM endpoint configuration, group-to-model mapping and knowledge permissions.	Your platform team owns the SCIM endpoint configuration, group-to-model mapping and knowledge permissions.	Your platform team owns the SCIM endpoint configuration, group-to-model mapping and knowledge permissions.
Session end after a user is removed	Without Redis, sign-out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Confirm how removal ends active sessions.	Without Redis, sign-out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Confirm how removal ends active sessions.	Without Redis, sign-out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Confirm how removal ends active sessions.

Mapping directory groups to Open WebUI model and knowledge permissions

Open WebUI's role-based access control is built on groups and per-resource permissions, so the design decision that matters most is which directory groups become Open WebUI groups and which models and knowledge collections each group can reach. Once SCIM pushes groups from Okta, Entra ID or Google Workspace, those groups become the inputs to that model. A user gains access to a model or knowledge collection through group membership, so the mapping determines who can see what on the first day of rollout. Settle this mapping on paper before you connect the identity provider, and confirm in your own test instance how membership interacts with the default role that new users receive and with resources shared directly to a user.

Agree a naming and ownership model before the first sync. A practical approach is a naming convention that encodes the application, the resource type and the access level, for example an illustrative pattern such as owui-kb-finance-read for read access to a finance knowledge collection. Keep model-access groups separate from knowledge-access groups so that a change to one does not silently change the other. Assign each group a named owner who approves membership and owns the resources shared with it. Record the directory group, the Open WebUI group, the granted resources and the owner in one inventory. Also decide who may create or rename groups in the identity provider, because SCIM makes the directory the source of truth for membership.

Broad groups are the most common source of over-permissioned access. A group such as all-staff or engineering that is shared with many models or knowledge collections gives every member access to all of them, and one directory change can expand that access across the whole deployment. Knowledge collections often hold documents with very different sensitivity, so a single broad grant can expose material that only a small team should read. Models can also differ in data handling terms, approved use or cost, so a broad grant lets users reach models they were never approved to use. Keep each grant narrow and tied to a purpose, and review the resource-to-group map on a fixed schedule set by your governance process.

Test the mapping with one pilot group before expanding it. Confirm that membership added in the directory appears in Open WebUI, that the pilot members see only the models shared with their group, and that knowledge collections grant read or write access exactly as designed. Remove a user from the pilot group and confirm that access is withdrawn, and note how long that takes in your setup. Check that users in no group receive only the default role you intended, and that an administrator-created group is not removed or altered by a sync. Test deprovisioning as well. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks, so confirm how revocation behaves in your deployment before you rely on it.

Open WebUI SCIM user provisioning setup, step by step

This sequence takes an Open WebUI deployment from a working sign-in path to a tested, documented SCIM setup that creates, updates and deactivates accounts and groups from your identity provider. Each step ends with a check, so the team knows when it can move on. Exact field names and endpoint paths come from the Open WebUI features documentation and should be confirmed against the version you run.

Confirm the deployment and sign-in path
The platform team confirms that Open WebUI runs on one of the official install methods: Docker or Docker Compose, Kubernetes with Helm, or pip install open-webui followed by open-webui serve. They also confirm that single sign-on already works for a test account through OIDC or LDAP, because SCIM handles account lifecycle and does not replace sign-in. If you run more than one replica, confirm that PostgreSQL, Redis and shared file storage are in place first, as the scaling guide requires. Done when a test user signs in through the identity provider and an administrator can open the admin settings.
Set the authoritative directory and group set
The identity owner names one directory, Okta, Entra ID or Google Workspace, as the source of truth for user accounts, and decides which groups will be provisioned. Keep the list short: only groups that map to a model access role, a knowledge base or an administrative function should cross over. Record an owner for each group, the person who approves membership changes, and what happens to a user's content when the account is deactivated. Done when a signed record lists the directory, the groups, the owners and the deprovisioning rule, and the team agrees that SCIM will be the only writer for provisioned accounts.
Configure the SCIM endpoint and token
An administrator enables SCIM provisioning in Open WebUI, generates a provisioning token and records the endpoint base URL that the identity provider will call. In the identity provider, the team creates the provisioning connection for the Open WebUI application and enters the endpoint and token. Store the token in your secrets manager and keep it out of tickets and chat. Confirm the setting names and endpoint paths in the Open WebUI features documentation against your installed version before you begin. Done when the identity provider's connection test succeeds and Open WebUI logs show an authenticated request from the provider.
Map user attributes and group membership
Using the attribute list in the features documentation, the team maps identity provider fields for username, email, display name and active status to the matching Open WebUI user attributes. They then map group membership to the approved group names and decide how group names are matched, so a rename in the directory does not orphan permissions. Each provisioned group is linked to the model access and knowledge permissions it should grant, and the team checks that no group grants administrative rights by accident. Done when a sample user's attributes and groups in the provider's preview match the expected Open WebUI result.
Run a pilot with one test group
The team assigns a small test group, drawn from IT or the platform team, to the Open WebUI application in the identity provider and runs a full provisioning cycle. The group set matches production so the pilot tests the actual mappings and permissions. They watch the provider's sync log and the Open WebUI user list for errors, duplicate accounts or unexpected role changes. Done when the pilot accounts appear with correct names, groups and access, and a second sync cycle makes no further changes, which shows the sync is stable.
Verify create, update, membership and deactivation
The tester runs four scripted changes against test accounts and records the result of each: create a user in the directory, change an attribute such as the display name, add or remove a user from a provisioned group, and deactivate a user. For each change, they check that Open WebUI reflects it in the user and group views and that access matches the new state. For deactivation, they also check whether an existing session still works, because without the shared state store described in the scaling guide, tokens stay valid until they expire, by default after 4 weeks. Done when all four changes behave as expected and the deactivated account is refused access.
Document the runbook and hand over
The team writes the runbook that operations will use after go-live. It covers where the token is stored and how it rotates, the group ownership table, the change process for adding a group, how to read sync errors, and the manual steps for deactivating a user during an incident. The runbook also records the Open WebUI and identity provider versions tested, and it sets a review point before any upgrade, since setting names can change between releases. Done when someone who did not build the setup has walked through the runbook and the on-call team can run one full provisioning cycle from it.

Running SCIM in a multi-replica Open WebUI deployment

Provisioning reliability in a multi-replica Open WebUI deployment depends on shared state. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, because SQLite does not handle concurrent writes from several processes well. SCIM creates, updates and deactivates user and group records, so a provisioning run from Okta, Entra ID or Google Workspace can write to the same database while users sign in on other replicas. Decide on PostgreSQL before you enable SCIM, and confirm with your platform team who owns its high availability, connection limits and backups.

For multiple replicas, the guide also calls for Redis as a shared state store for sessions, websocket connections and application state, along with shared file storage so uploads and knowledge stay reachable from every replica. The session behavior matters most for deprovisioning. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. In that setup, deactivating a user in the identity provider and receiving the SCIM update does not by itself end an active session. Treat Redis as a hard requirement for any deprovisioning control you plan to rely on.

The default ChromaDB can crash in multi-process setups, so the scaling guide requires an external vector database when you run several workers or replicas. Open WebUI supports 13 vector databases, including PGVector, Qdrant, Milvus and Elasticsearch, so choose one your team can operate and back up, then validate it under concurrent load in staging. SQLite remains acceptable only for single-replica deployments, evaluation and small teams, and only when the database file sits on locally attached SSD or NVMe storage. A pilot with one SQLite replica can hide the write contention and session problems that appear once production runs several replicas.

Before go-live, confirm the session and token behavior for the exact Open WebUI version you deploy, because the answer depends on configuration and release. Ask your vendor or check the release notes for the token lifetime, whether deactivation through SCIM revokes existing tokens, and how API keys behave for a deactivated user. Then test it: deactivate a test account in the identity provider, confirm that its browser session, websocket connection and API calls fail within the window your security policy accepts, and keep the results as evidence for your access review.

Security risks in SCIM deprovisioning and token lifetime

Automated provisioning removes accounts and group memberships, but only if every link in the chain works and is checked. The risks below cover what happens when a leaver is not removed, when sessions outlive sign-out, when group grants are too broad, and when the SCIM credential itself becomes the weakest point.

Leaver accounts left active

A SCIM deactivation request that is sent but not applied leaves the former employee able to sign in, and an account that keeps its group memberships keeps its model and knowledge access. Test the path end to end with a disposable test user: deactivate in the identity provider, then confirm the Open WebUI account is inactive, sign-in fails, and existing group memberships are removed. Repeat after each upgrade and identity provider change, and record the result.

Long-lived tokens after sign-out

Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. A deprovisioned user's existing session can therefore keep working even after the account is disabled, depending on how requests are validated in your deployment. Confirm your topology before go-live, and if you run multiple replicas, plan the shared state store that makes sign-out and revocation behave consistently across instances.

Over-broad group grants

Mapping an identity provider group to a broad role can give a large population access to every model and every knowledge collection. Map groups to the narrowest model and knowledge permissions that match real work, and review which groups hold administrator rights. Verify by signing in as a test user from each group and listing the models and knowledge bases that appear, since that list is what the group actually grants.

SCIM bearer credential handling

The SCIM bearer token lets the identity provider create, change and delete accounts, so it is a privileged credential. Store it in a secrets manager rather than in configuration files, limit who can read it, and define a rotation procedure that updates the identity provider and the Open WebUI side together. Verify that a rotation can be completed without a provisioning gap and that the old token is rejected afterward.

Audit trail for provisioning events

Provisioning changes made by SCIM can be hard to attribute when the only record sits in the identity provider. Confirm which create, update, deactivate and group events Open WebUI logs, where those logs go, and how long they are kept. Test by provisioning and deprovisioning a test user, then trace both events from the identity provider log to the Open WebUI log using the same user identifier.

Policies SCIM does not replace

SCIM manages account lifecycle and group membership, but it does not enforce multi-factor authentication or govern API keys. Decide whether authenticator-app MFA is enforced at sign-in in the identity provider or in Open WebUI, and whether users may create API keys that outlive their employment. Verify each policy with a test account, and document which owner reviews API keys and how keys are revoked when a user leaves.

What does Open WebUI SCIM provisioning cost and take to implement?

Does Open WebUI SCIM provisioning need a separate license or enterprise plan?

It depends on how many users you will have and whether you need to change the branding. The Open WebUI License forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Below that threshold, the branding clause does not apply to your deployment. Enterprise licenses add white-labeling, custom branding and dedicated support options. Open WebUI's enterprise documentation says pricing is not published and is quoted after you contact enterprise sales with an expected seat count. Before you commit, have counsel read the current license text against your user forecast, and ask the vendor how the seat count is measured and what renewal terms apply.

How much does Open WebUI SCIM provisioning cost to implement?

No price is published for this work, and DeployOpen does not publish a price list. A quote follows from a written scope. The main cost components are the identity provider work in Okta, Entra ID or Google Workspace, group design and approval, the Open WebUI deployment changes needed for multiple replicas, testing, and the cutover. One-time costs include design, build, testing and cutover. Recurring costs include group changes, upgrades, license fees if you need an enterprise license, and any support retainer. Ask for a quote that lists each component separately, states which items are one-time and which recur, and names what the client must supply. Ask how changes after go-live are priced.

Can an internal team set up SCIM provisioning for Open WebUI alone?

Often yes, if the team already runs both the identity provider and the Open WebUI deployment. Open WebUI documents SCIM 2.0 user and group provisioning, so most of the work is configuration, mapping and testing rather than custom code. The gaps usually appear in three places: group policy, which needs a business owner, multi-replica state, which needs PostgreSQL, Redis, shared file storage and an external vector database, and testing across the full user lifecycle. Check whether your team has staff with directory administration rights, has done multi-replica work before, and can give the project steady time. If one of those is missing, a partner can take a fixed-scope part of the work while your team keeps ownership.

What do we need to provide for a SCIM provisioning engagement?

Most of what the work needs comes from your side. You need directory administrators who can create the application integration and SCIM credentials in your identity provider. You need a test tenant or sandbox directory where users and groups can be created and changed without affecting production. You need a named owner for group policy who decides which directory groups map to which models, knowledge bases and tools. You need access to the environment where Open WebUI runs, including the database, cache and storage, and a change window for cutover. You also need an approver who signs off on test results. Confirm these roles early, because delays in group decisions and test access are common causes of schedule slip.

Why does group design drive the effort in SCIM provisioning?

Group design determines what each user can reach, so it is the decision that takes the most agreement. Open WebUI uses groups for role-based access control and per-resource permissions, so each directory group you provision maps to access to models and knowledge. Overlapping groups, nested groups and unclear ownership create permissions that are hard to explain later. Before the build, agree on a naming standard, one owner for each group, a rule for which groups grant access and which only label people, and a review schedule. Changes to group design after go-live need the same review, which is why group policy is a recurring cost as well as a one-time task.

What breaks when Open WebUI runs several replicas with SCIM?

Most failures come from running a single-instance setup across several replicas. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments and Redis for shared sessions, websocket connections and application state. Uploads and knowledge need shared file storage so every replica can reach them. The default ChromaDB will crash in multi-process setups, so you need an external vector database. Without Redis, signing out does not revoke tokens, and they stay valid until they expire, by default after 4 weeks. That means a user removed through provisioning can keep access until the token expires unless you verify session behavior in your own test. Check each of these items in your environment before you rely on the setup.

How do we verify SCIM deprovisioning before going live?

Test the full lifecycle in the test tenant, not only account creation. Create a test user, assign groups, confirm the expected models and knowledge are visible, change group membership, confirm access changes, and then disable the user in the identity provider. For each step, check the Open WebUI account state, the group membership, and what the user can still reach. Include a test of an active session and a token issued before the change, so you can see how long access persists in your deployment. Record the results and the exact identity provider and Open WebUI versions tested. Confirm the attributes and endpoints you rely on against the current vendor documentation, because provisioning behavior can change between releases.

What ongoing work follows after SCIM provisioning goes live?

Ongoing work covers four areas: Open WebUI upgrades, identity provider changes, group policy reviews and monitoring of provisioning results. Upgrades need a test pass against your SCIM setup because releases change, and the license changed for releases from v0.6.6, so review the license terms before each upgrade. Identity provider changes, such as new applications or changed attribute mappings, can break provisioning silently. Group reviews keep access aligned with roles. Your team may keep this work in-house or buy it as a retainer, which covers ongoing support, upgrades and continuous testing. Ask any partner to state in writing what the retainer covers, how often reviews happen, and how urgent issues are handled.

Limits to confirm in your environment before rollout

Open WebUI SCIM behavior depends on the exact release, the identity provider's connector and the deployment topology around it. Each card names one item to confirm, who should confirm it, and the test that proves it before users depend on it.

Supported SCIM operations and attributes

Confirm which SCIM 2.0 operations Open WebUI accepts for users and groups in the exact release you plan to deploy, including create, update, replace and delete. Confirm which user attributes it maps, such as email, display name, active status and external identifier. Do not assume that SCIM support described in general applies to your version. Check the release notes, then send test payloads from your IdP so attribute mismatches appear in the pilot rather than in production. Owner: vendor documentation, then a pilot test.

Deactivation versus deletion

Confirm what happens when the IdP deactivates a user and when it deletes one. Deactivation may block sign-in while keeping chats, uploads, knowledge and API keys, and deletion may remove them, so the outcome shapes your offboarding and retention process. Test both events on a pilot account and check whether existing sessions end immediately. The scaling guide notes that without Redis, tokens stay valid until they expire, by default after 4 weeks. Owner: pilot test with the IdP admin.

Group sync and membership removal

Confirm how group pushes from the IdP create and update Open WebUI groups, and what happens when a user leaves a group in the IdP. Removing membership must also revoke the model and knowledge access that the group granted, or access lingers after a role change. Check whether changes apply immediately or at the next sync, how nested groups are flattened, and whether groups deleted in the IdP are removed or left behind. Owner: pilot test, because behavior depends on the IdP's push settings.

Provider connector setup for Okta, Entra ID and Google Workspace

Each provider has its own SCIM app or connector, with separate attribute mappings, push options, group handling and authentication for the SCIM endpoint. Confirm the setup steps for your provider in its current documentation, and confirm the Open WebUI side, including the SCIM token and base URL. Record which provider features, such as group push or deprovisioning, the connector supports before you promise them to users. Owner: the IdP admin for each provider, verified by a pilot test.

License and branding obligations for your user count

Since v0.6.6 (April 19, 2025), Open WebUI code ships under the Open WebUI License. That license forbids altering or removing branding in deployments that exceed 50 users in any rolling 30-day period, unless you hold an enterprise license or written contributor permission. Count active users against this threshold before rollout, because SCIM can add users quickly once it is connected. Enterprise pricing is not published, so request a quote with your expected seat count. Owner: the license documentation and your legal or procurement team.

Vector database and storage across replicas

The scaling guide requires PostgreSQL for multi-instance deployments, Redis for shared session and application state, and shared file storage so uploads and knowledge stay reachable from every replica. It also warns that the default ChromaDB crashes in multi-process setups, so choose one of the 13 supported vector databases to run externally and test it under concurrent replicas. Confirm that a deprovisioned user loses access on every replica, not only the one that handled the request. Owner: vendor scaling documentation, then a pilot test.

How DeployOpen scopes and delivers Open WebUI SCIM provisioning

DeployOpen plans and implements Open WebUI SCIM 2.0 provisioning inside your own infrastructure, keeping account and group lifecycle in your identity provider while sign-in is handled separately. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which identity provider (Okta, Entra ID or Google Workspace) owns users and groups, and which tenant or domain is in scope.
Map IdP groups to Open WebUI groups and the model and knowledge permissions each group should receive.
Record how the SCIM connection will sit alongside the chosen sign-in method, so provisioning and login are designed as separate decisions.

How we build

Configure the SCIM 2.0 endpoint and token handling in your Open WebUI deployment, with secrets stored in your chosen vault.
Set up the identity provider's provisioning app for create, update and deactivate events, then test each lifecycle case against a non-production group.
Document group-to-permission mappings and check that removing a user from a group in the IdP changes their access in Open WebUI as designed.

How we hand over

Deliver a written configuration record covering the IdP settings, Open WebUI group mappings, token rotation steps and rollback procedure.
Walk your identity and platform teams through the test results, including deprovisioning cases and any known gaps in your environment.
Provide an operations runbook for onboarding a new group, rotating credentials and investigating a failed sync.

How we support

Ongoing support, upgrades and re-testing after Open WebUI or identity provider releases are available as a retainer.
Review SCIM behavior when you upgrade Open WebUI, since the license and release notes for newer versions should be checked before the upgrade.
Confirm with your identity provider and Open WebUI documentation which SCIM features your plan and version support before the build starts.