How authentik sign-in for Open WebUI works and who should own it
When Open WebUI must sit behind company sign-in, authentik acts as the OAuth2/OpenID provider that Open WebUI trusts for user login. The authentik integrations guide for Open WebUI describes this setup: you configure an OAuth2/OpenID provider in authentik for Open WebUI, and Open WebUI sends users to authentik to sign in. The integration covers four pieces: the provider and application in authentik, the OAuth settings on the Open WebUI side, the claims that carry user identity and group membership, and the decision to turn off local account creation so that company sign-in is the only way in. Each piece touches a different team, so it helps to name the owner of each before configuration starts.
Your identity team usually owns the authentik side: the provider, the application, the redirect URI, which groups are allowed to reach Open WebUI, and how group membership is emitted in the token. Your AI platform or application team owns the Open WebUI side: the environment settings, how admin and user roles are assigned from claims, and whether local signup is disabled. Someone must also decide who is an Open WebUI administrator, since that role controls model connections, user management and the data every user can reach. Confirm in the integrations guide and the Open WebUI documentation which claims and settings your installed versions expect, because the Open WebUI releases page shows frequent changes across versions.
The integration does not cover everything around the chat tool. The model providers Open WebUI connects to, the vector databases used for retrieval, the scaling design for multiple replicas, and the decision to adopt an Open WebUI enterprise license all need their own owners and their own quotes. Open WebUI's license also changes what branding you may alter once deployments exceed a user threshold, so legal or procurement should review that before rollout. Ask your DeployOpen contact to put each owner, decision and open question into the written scope so the sign-in work and the platform work are not assumed to be the same project.
What you need in place before configuring Open WebUI and authentik
Four pieces must be in place before any OAuth settings are entered: a running authentik, a running Open WebUI, public DNS and TLS for both, and an agreed group structure. Each card below is a check to complete first, because a mismatch in any one of them usually shows up later as a failed login or an account with the wrong access.
A supported authentik release line
Confirm your authentik server and worker run a release line that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance. Pick one of these lines and record the exact version, since the OAuth provider settings and the claim names you configure depend on it. Plan to keep authentik on a supported line for the life of the integration.
Open WebUI on a supported install method
Open WebUI should already run through one of its official install methods: Docker or Docker Compose, Kubernetes with Helm, or pip with open-webui serve. Record the exact image tag or package version you deploy, because the license and feature set change across releases. Confirm the instance answers on its intended public address before adding SSO, so that a failed OAuth login is not confused with a basic installation fault.
DNS and TLS for both public URLs
authentik and Open WebUI each need a stable HTTPS address, and the OAuth redirect URI registered in authentik must match the address users see in the browser exactly, including scheme and path. Decide both hostnames before configuring anything, because changing them later means updating the authentik provider and the Open WebUI environment together. Confirm the certificate chain is trusted by the browsers and servers involved.
Scaled-out Open WebUI needs PostgreSQL and shared storage
A single Open WebUI instance can run on its default local database for a pilot. Multiple replicas are different: Open WebUI's scaling guide requires PostgreSQL instead of SQLite, because SQLite does not handle concurrent writes from several processes well. Multiple replicas also need Redis for sessions, websocket connections and application state, plus shared file storage so uploads and knowledge stay reachable from every replica. Decide the replica count before you configure SSO.
A group structure that maps to access
Decide which authentik groups will carry admin rights and which will carry standard user access before you create the OAuth provider. Keep the group names short, stable and unique, because they become the values Open WebUI reads from the token. Document who approves membership in each group and how a user leaves it. Agree this with the team that owns authentik, since group membership in authentik becomes the source of truth for who can sign in to Open WebUI.
A local administrator account kept as a fallback
Before disabling local signup, confirm that at least one local administrator account exists in Open WebUI and that its credentials are stored in your password vault. If the OIDC provider is unreachable or the role mapping is wrong, this account is the way back in to correct the configuration. Test that the account can sign in before you change any login setting, and record who holds it and where it is kept.
Configure the authentik provider and Open WebUI in sequence
This sequence connects Open WebUI to authentik over OAuth so users sign in with company accounts and receive roles from group claims. It ends with local signup turned off and a verified non-admin login, so the team can confirm access works before local accounts are closed.
Create the OAuth2/OpenID provider in authentik
In the authentik admin interface, an administrator creates an OAuth2/OpenID provider for Open WebUI, following the Open WebUI guide in the authentik integrations catalog. Choose the signing key, scopes and the client type the guide specifies, and confirm that the provider includes the profile, email and group scopes Open WebUI needs to read identity and role data. The step is done when the provider saves and shows an OpenID configuration endpoint you can open in a browser.
Bind an application to the provider
Create an application in authentik that uses the new provider, and set its name, launch URL and access policy. Use a group or policy binding so only the intended user populations can reach the application. The check is that a test user who is in the bound group sees the Open WebUI tile in the authentik user interface, while a user outside the group does not.
Record the client ID and client secret
Copy the client ID and client secret from the provider and store them in your secrets manager, not in a shared document or chat thread. Also record the OpenID discovery URL for the provider, which Open WebUI needs to find authentik's endpoints. The check is that each value is stored in a location that only the people who deploy Open WebUI can read, and that the secret is never printed in deployment logs.
Set the redirect URI in authentik
Add the callback URL for your Open WebUI deployment to the provider's allowed redirect URIs. The path and format are given in the authentik Open WebUI guide, and the host must match the address users type in their browser, including the scheme and port. The check is that the redirect URI in authentik matches the one Open WebUI sends during sign-in, because a mismatch stops the flow before any user reaches the chat interface.
Configure the Open WebUI OAuth settings
Set the OAuth-related environment settings on the Open WebUI deployment, including the client ID, client secret, OpenID discovery URL, provider display name and requested scopes. Confirm the exact setting names against the Open WebUI configuration reference for your release, since the version in use determines which keys apply. Restart the service, then open the login page. The check is a visible sign-in option that sends the browser to authentik and returns to Open WebUI after the user authenticates.
Map group claims to Open WebUI roles
Configure the claim or group setting that tells Open WebUI which authentik groups grant administrator access, and which groups grant ordinary user access. Keep the admin group small and named clearly, and assign it only to the people who will manage models and users. Sign in as a test user from the admin group and as a test user from the standard group, then check the role shown in each session. The check is that each test account receives the role its group should carry.
Test a non-admin login before disabling local signup
Sign in with a standard test user who is not in the admin group, using only the single sign-on option. Confirm that the callback completes, the user reaches the chat interface, and the user cannot open administration pages or change global settings. Review the session or user profile to verify the group claim arrived as expected. Do not proceed until this test passes, because disabling local signup before this point can lock out every account that depends on it.
Disable local signup and keep a break-glass account
After the non-admin test passes, turn off self-registration and the local login form in the Open WebUI settings your release supports, and confirm the names in its configuration reference. Keep one documented local administrator account for recovery, store its credentials in the secrets manager, and test that the account still works before you close other access paths. The check is that a new visitor cannot create an account from the login page, and the recovery account signs in successfully.
How group claims decide admin and user access
In an OAuth setup, authentik builds the token and user information response from the user's attributes and the scope mappings attached to the Open WebUI provider. Group membership reaches Open WebUI only when a mapping includes it in the requested scopes. Open WebUI then reads that list during sign-in and decides the role. Names matter at both ends, so the group claim key configured in authentik has to match the key the current Open WebUI release reads.
- Scope mapping: Confirm that the provider includes a groups mapping in the scopes the Open WebUI client requests.
- Claim key: Record the exact claim name the authentik guide uses and the name the current Open WebUI release expects, since these can change between releases.
- Group naming: Use stable, descriptive group names in authentik, because those names become the values Open WebUI matches against.
- Refresh timing: Ask whether a group change in authentik takes effect at the next sign-in or only after an existing session ends, then test with a user who is already signed in.
Check the claim key and scope list against the authentik Open WebUI guide before writing any role rules.
Admin access in Open WebUI covers user management, system settings and model configuration, so it should be the narrowest group in the design. Keep the admin group in authentik limited to people who need that control, and make membership an explicit approval step owned by the security or platform team. Avoid inheriting admin rights from a broad department group, since a change to that department would silently change who controls the platform.
- Dedicated group: Create one admin group in authentik that no other application uses to grant administrative rights.
- Membership review: Assign a named owner who reviews membership on a fixed schedule and removes access when someone changes roles or leaves.
- Recovery path: Plan how an administrator signs in if the identity provider is unavailable, and confirm how the current release handles local login when SSO is enforced.
- Role test: Sign in with one member of the admin group and one non-member, then confirm that only the member sees administrative areas.
Verify the assigned role in the Open WebUI user list after a fresh sign-in rather than relying on a session that was already open.
Standard users need to chat with the models your organization has approved and little else. Map a general user group in authentik to the standard user role, then set what that group can reach inside Open WebUI. The features documentation describes role-based access control built on groups and per-resource permissions, so model access, knowledge and tools should be assigned to groups deliberately instead of left at their defaults.
- Group-to-role mapping: Map the user group to the standard role only, so membership grants chat access and nothing administrative.
- Model permissions: Decide which models each group may use, and set those permissions in Open WebUI after the role is assigned.
- Knowledge and tools: Review who can create knowledge bases or enable tools, since these features can expose internal documents or external connections.
- Users outside every group: Decide whether a signed-in user with no matching group is denied, given a minimal role or placed in a pending state, and test that path.
Test one account from each group against the approved model list before opening access to the wider organization.
When a user signs in for the first time and matches no admin or user group, the default role decides what that account can do. Treat this setting as a security control, not a convenience. Confirm which default role the current release applies to new accounts created through SSO, and whether signup, pending approval or automatic activation is involved. Document the answer, because the behavior can change between releases.
- Least privilege: Set the default to the most restricted role that still lets approved users reach their work.
- Approval flow: If new accounts need review, confirm whether they wait in a pending state and who is responsible for approving them.
- Local signup: Disable local account creation so that every new user passes through authentik, and confirm the matching environment setting in the authentik Open WebUI guide.
- Existing local accounts: Decide what happens to accounts created before SSO, including whether they keep local passwords and whether their roles carry over.
Create a new test user outside all groups and confirm the role and approval state that account receives before you rely on the default.
Which authentik attributes map to which Open WebUI fields
This table compares each user attribute authentik can send over OAuth with the Open WebUI field it fills and how it affects account matching. Read the right column as the lab checklist: the guide confirms the provider setup, but several claim names and matching rules must be tested in your own instance before you rely on them.
| Field | authentik source | Open WebUI behavior |
|---|---|---|
| Username | User username, sent only if the provider scope and claim mapping include it | Verify in lab which claim fills the Open WebUI username and whether it is used to match an existing account |
| User email attribute, sent in the email claim when the email scope is granted | Confirm whether Open WebUI links existing local accounts by email before you enable SSO for current users | |
| Display name | User name attribute, sent in the name claim | Verify which claim populates the display name and whether it refreshes at each sign-in |
| Groups | Group memberships, sent in a groups claim through a custom property mapping | Confirm the claim name and whether group names control admin access, user access or both |
| Changed username or email | Attribute edited in authentik after the account already exists | Verify in lab whether the next sign-in updates the existing account or creates a second one |
| Removed group membership | User removed from an authentik group that grants access | Verify whether the role is downgraded or access removed at the next sign-in, and whether existing sessions end |
Hardening the sign-in path for AI chat
Once SSO works, the sign-in path is only as strong as its weakest entry point. Local signup, password login, client secrets, transport security and API keys each provide a way around the company identity provider if left unchecked. The cards below cover what to close, what to verify in both products, and what to confirm in the release you deploy.
Disable local signup and password login
After the OIDC login succeeds for every intended user, turn off self-registration and local password sign-in in Open WebUI so that authentik is the only way in. Keep one documented break-glass administrator account and test it before the change, because a misconfigured OIDC setting can otherwise lock out everyone, including administrators. Confirm the exact configuration keys for disabling signup and local login in your Open WebUI release, since these settings have changed across versions. Test the break-glass path before you need it.
Restrict self-registration in authentik
Even with local signup disabled in Open WebUI, authentik can create accounts through enrollment flows if they are bound to the application. Review which flows, invitations and source mappings can create users, and confirm that new accounts land only in groups your access policy expects. Check whether the authentik application requires an assigned user or group binding before login, so that a valid authentik account does not automatically receive Open WebUI access.
Enforce MFA through authentik
Open WebUI documents authenticator-app MFA as a feature of its own, but the stronger control is to require the second factor in authentik at the flow or policy level so it applies before the OIDC token is issued. Decide which users or groups must complete MFA, and confirm whether Open WebUI's own MFA setting is still needed or conflicts with the authentik flow in your release. Verify both behaviors with a test account.
Protect the OAuth client secret
The client secret that Open WebUI uses to exchange authorization codes is a credential that grants access to the application. Store it in a secrets manager or an environment file with restricted permissions, not in a compose file committed to version control. Rotate it when administrators change, and confirm in authentik whether the client type is confidential, since public clients do not use a secret and should not be configured as if they do.
Serve both URLs over HTTPS
Open WebUI's public URL and authentik's issuer URL both need HTTPS, and the redirect URI registered in authentik must match the Open WebUI address exactly, including scheme and port. Mixed or mismatched URLs cause login loops or token rejection, and plain HTTP exposes session cookies and authorization codes on the network. Confirm the certificate chain is trusted by the Open WebUI container, since a private certificate authority often needs to be added to the container trust store.
Review API keys issued through Open WebUI
Open WebUI supports API keys, which can outlive an SSO session and keep working after a user leaves the company. Decide whether API key creation is allowed for normal users, and set a review process that lists keys by owner and removes those belonging to departed or deprovisioned accounts. Deprovisioning in authentik should be paired with a check of Open WebUI API keys, and you should confirm how the release handles keys for disabled users.
Common failures when Open WebUI sign-in breaks
This table lists the sign-in failures teams most often hit when Open WebUI is connected to authentik over OAuth, with the likely cause and the fix or check for each. Work through the rows in order, since a wrong issuer or redirect URI blocks every later test. The main takeaway is that most failures come from a small set of settings that must match exactly on both sides.
| Failure | Likely cause | Fix or check |
|---|---|---|
| Redirect URI mismatch after sign-in | The redirect URI registered in the authentik OAuth2/OpenID provider does not exactly match the callback URL Open WebUI sends, often because of http versus https, a missing path segment or a different hostname. | Compare the redirect URI in the authentik provider with the public Open WebUI URL and callback path in the Open WebUI guide. Check the scheme, port and trailing slash, then retry in a private browser window. |
| Wrong issuer or discovery URL | The OpenID issuer or well-known discovery address points to the wrong application slug, an internal hostname, or a provider from another application in authentik. | Open the discovery document in a browser and confirm its issuer value matches the value Open WebUI is configured to use. Confirm the application slug in the URL matches the one you created. |
| Users sign in but get no admin rights | The group or role claim is missing from the token, the claim name differs from what Open WebUI reads, or the user is not a member of the mapped authentik group. | Inspect the token or user info response for the claim. Confirm the scope mapping includes the claim, the claim name matches the Open WebUI setting, and the user is in the intended group before signing in again. |
| Users locked out after disabling local signup | Local signup was turned off before any SSO user had been created, or the only local administrator account was never migrated or kept as a recovery path. | Keep one local administrator account reachable until SSO admin sign-in is verified. Test SSO login with a non-admin and an admin account before turning off local signup, and record the recovery steps. |
| Duplicate accounts after an email change | Open WebUI matches users by email, so a changed email in authentik creates a new account while the old one keeps its chats, files and permissions. | Decide the matching identifier before go-live and keep email stable in authentik. Where an account is duplicated, merge or reassign it through an administrator in Open WebUI and confirm which identifier the OIDC claims supply. |
| Login loops or callback errors behind a reverse proxy | The proxy terminates TLS but Open WebUI builds URLs with the internal scheme or host, or forwarding headers such as the original host and protocol are stripped or not trusted. | Set the public URL that Open WebUI advertises, pass forwarded host and protocol headers from the proxy, and confirm the authentik server URL is reachable from the Open WebUI container. |
| Clock or token validation errors | Server clocks differ between the authentik host and the Open WebUI host, so tokens appear expired or not yet valid. | Confirm both hosts use synchronized time sources and compare timestamps in the logs of each service when validation fails. |
| Sign-in works in testing but fails for other users | The authentik application binding or policy excludes some users or groups, or the Open WebUI group settings do not include the groups those users belong to. | Test with a user from each intended group. Review the application bindings in authentik and the group mapping in Open WebUI, and confirm that the expected groups appear in the claim for each test user. |
Keeping the integration working through upgrades and replicas
Plan to retest the Open WebUI OAuth settings after every Open WebUI upgrade and every authentik upgrade, because either side can change how the sign-in flow behaves. Open WebUI moves quickly: v0.12.0 was published on October 10, v0.12.3 followed on October 16, 2026, and v0.11.0 came out in July. Each release is a point to repeat the login test: sign in as a user with the user role, sign in as an admin, confirm that the OAUTH_ROLES_CLAIM mapping still assigns the right roles, and confirm that local signup stays disabled. Keep a short written test script so the same checks run each time, and record which Open WebUI and authentik versions passed.
On the authentik side, upgrades must follow the sequential upgrade rule, so move through each required release in order rather than jumping several versions at once. Check the authentik security policy for the release lines that currently receive security fixes, and confirm your target version against the authentik releases page before you schedule the change. Read the release notes for every version you cross, since they may change provider behavior, token claims or PostgreSQL connection use. The 2025.10 notes, for example, record that authentik no longer uses Redis and warn about roughly 50% more PostgreSQL connections after upgrading, which matters if you run Open WebUI against the same database server.
Multiple Open WebUI replicas change the sign-in design. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, and it requires Redis for sessions, websocket connections and application state, plus shared file storage so uploads and knowledge stay reachable from every replica. Because each replica must see the same session state, confirm that the OIDC redirect URI points to your single public hostname and that the load balancer keeps requests consistent through the login callback. Decide early whether Redis is run by your platform team or a managed service, and confirm with your authentik and Open WebUI deployment owners how the OAuth client secret is stored and rotated across all replicas.
Questions buyers ask before connecting Open WebUI to authentik
How much does it cost to connect Open WebUI to authentik?
The cost is driven by labor, not by a license fee for the integration itself, because the OAuth setup uses the authentik Open Source edition and Open WebUI's SSO features. Effort rises with the number of groups that need different access, the number of Open WebUI replicas, the MFA policy you enforce in authentik, and how much testing you require before users are moved over. Ask any partner for a quote built from a written scope that lists each of these items, and separate one-time setup from recurring work such as upgrades and access reviews. If you plan to use authentik Enterprise features, the pricing page lists them as paid, so include those licenses in the comparison.
How long does an authentik and Open WebUI SSO setup take?
No fixed duration applies because the time depends on your environment and on approvals you do not control. The technical configuration of the provider, the client settings and the role claims is usually the shorter part. The longer parts are agreeing on the group model with the people who own each group, getting DNS and TLS records issued, scheduling the change window for the switch from local accounts, and testing admin and user logins across every path your users take. Ask for a timeline that names each approval and dependency rather than a single number.
What do we need to provide before the work starts?
You need four things ready before the engagement begins. First, administrator access to authentik with the rights to create providers, applications, groups and property mappings. Second, DNS records for the Open WebUI hostname and the authentik hostname, plus a TLS certificate path that both sides trust. Third, named owners for each group that will grant admin or user access, who can confirm membership rules. Fourth, a test user set in authentik and a staging or pilot Open WebUI instance where changes can be checked before production. Confirm the exact details with your authentik and Open WebUI administrators, since these depend on your network design.
Can our team set up Open WebUI SSO with authentik without a partner?
Yes, a team with experience running authentik and Open WebUI can do this in house, and the authentik integration guide for Open WebUI is the starting point for the provider setup. The skills that matter most are OAuth2 and OpenID Connect configuration, reading the claims that authentik sends, and writing Open WebUI environment settings correctly. Check whether your team has someone who will own the configuration after go-live, since changes to groups, claim names or the signup setting affect every user. Outside help is most useful when the team lacks these skills or when the platform also needs hardening and testing.
Does the Open WebUI License apply to our deployment?
It can. Since v0.6.6, Open WebUI code is distributed under the Open WebUI License, which adds a branding protection clause. That clause 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. Code through v0.6.5 remains BSD-3-Clause. Count the users who will sign in through authentik, not only the admins, and ask Open WebUI's enterprise sales team how the license applies to your seat count before you rebrand the interface.
Which authentik features require an Enterprise license for this setup?
The OAuth2 and OpenID Connect provider used for Open WebUI is part of the open-source core, so basic sign-in does not need an Enterprise subscription. The authentik pricing page does list several features as Enterprise only, including Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history and enhanced audit logging. Decide early whether you need any of these, for example audit logs for access reviews or directory provisioning. Confirm the current feature split on the pricing page before you finalize scope, because the edition boundaries are set by the vendor.
When should we bring in outside help for this integration?
Bring in outside help when the group model is contested, when several Open WebUI replicas and shared storage must be configured, or when you need the integration tested and documented for a compliance review. A replicated deployment needs PostgreSQL instead of SQLite and Redis as a shared state store, so the architecture work is larger than the SSO change itself. DeployOpen plans and implements these integrations under a written, fixed scope, and it prepares evidence for compliance assessments without issuing audit reports. Ongoing upgrades and testing are available as retainers if you want them after go-live.
What goes wrong most often with Open WebUI OAuth sign-in?
The most common failures are mismatched redirect URIs, a client secret copied incorrectly, and claims that do not match the names Open WebUI expects for roles or groups, so users sign in but land with the wrong access. Local signup left enabled is another frequent problem, because users can create accounts outside authentik. Check each of these in a pilot before the cutover. Keep a documented admin path for recovery, and confirm the exact environment setting names in the current Open WebUI documentation for your version.
How DeployOpen scopes and delivers this integration
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the authentik and Open WebUI SSO integration described here. We agree the scope in writing before work starts, so the OAuth provider, claim mapping, login settings and signup controls are defined and priced from the same written document.
How we scope
- Confirm your authentik version, Open WebUI version and how each is deployed before choosing the design.
- Agree which groups map to Open WebUI administrators and which map to standard users.
- Record the decision on local signup, break-glass access and the users who keep a local admin account.
How we build
- Configure the OAuth2/OpenID provider and application in authentik, then set the matching OAuth environment values in Open WebUI.
- Test role and group claims with a small pilot group before any broad rollout to staff.
- Verify that local signup is disabled, that existing accounts sign in as expected, and that admin access is limited to the agreed group.
How we hand over
- Deliver a written runbook covering provider settings, environment variables, claim mappings and the group-to-role table.
- Document the rollback path, including how to re-enable local login if the identity provider is unavailable.
- Walk through the configuration with your identity and platform teams so they can change group rules themselves.
How we support
- Support is available as a retainer for upgrades when authentik or Open WebUI releases change OAuth or claim behavior.
- Retainers can cover re-testing claim mappings after group changes, user onboarding issues and login incidents.
- Confirm response expectations and any service levels in the written retainer before work starts.
