SSO (OAuth, OIDC, Trusted Header)
关于所有环境变量的更多信息,请查看 环境变量配置文档页面。 强烈建议阅读该环境变量页面,以获取有关如何设置变量以及预期值的更多细节。
在排除 SSO 设置故障时需要帮助? 请查看我们的 故障排除指南
目前,您一次只能通过 OPENID_PROVIDER_URL 配置一个 OpenID Connect (OIDC) 提供商。
您不能同时将 Microsoft 和 Google 配置为 OIDC 提供商。
然而,社区有一个同时使用两者的解决方法!有关更多细节,请参阅我们的 双 OAuth 教程。
OAuth 配置概述
| 环境变量 | 默认值 | 描述 |
|---|---|---|
WEBUI_URL | — | 必填。 您的公开 WebUI 地址,例如 http://localhost:8080。 |
ENABLE_OAUTH_PERSISTENT_CONFIG | true | 将 OAuth 配置持久化到数据库中;在无状态/容器化环境中请设置为 false。 |
ENABLE_OAUTH_SIGNUP | false | 允许通过 OAuth 登录时创建账户(独立于 ENABLE_SIGNUP)。 |
OAUTH_MERGE_ACCOUNTS_BY_EMAIL | false | 根据匹配的电子邮件合并 OAuth 登录(警告:如果提供商未验证电子邮件,这可能是不安全的)。 |
OAUTH_UPDATE_PICTURE_ON_LOGIN | false | 每次登录 时,从 OAuth 提供商更新用户个人资料图片。 |
OAUTH_PICTURE_CLAIM | picture | Claim 中包含个人资料图片的字段。设置为空字符串以禁用图片更新(用户将获得默认图标)。 |
ENABLE_PROFILE_IMAGE_URL_FORWARDING | true | 当为 true 时,后端在 /api/v1/users/{id}/profile/image 接口上发出 302 重定向,指向 IdP 写入 profile_image_url 的外部 URL。随后每个浏览器将直接从该源加载头像 —— 这会泄露客户端 IP、User-Agent 和 Referer 请求头。设置为 false 可以抑制该重定向;IdP 提供的 URL 仍会被存储,但 Open WebUI 会代以提供内置的默认图片。建议: 除非您的 IdP 返回头像为 data: 格式的 URI(Open WebUI 会将其持久化在本地,不受影响),或者您接受由于显示由 IdP 托管的头像而带来的数据泄露风险,否则请将其禁用。参见 ENABLE_PROFILE_IMAGE_URL_FORWARDING 以了解完整语义。 |
WEBUI_AUTH_SIGNOUT_REDIRECT_URL | 空 | 用户登出后重定向到的 URL。例如 https://your-company.com/logout-success |
WEBUI_SECRET_KEY | 空 | 必须设置 - 特别是在集群环境中。否则会出现会话问题和奇怪的 OAuth 问题。 |
OAUTH_SESSION_TOKEN_ENCRYPTION_KEY | WEBUI_SECRET_KEY | 用于加密存储在服务器上的 OAuth Token 的密钥。必须在集群中的所有实例之间共享。 |
OAUTH_CLIENT_INFO_ENCRYPTION_KEY | WEBUI_SECRET_KEY | 用于加密存储在服务器上的 OAuth 客户端信息的密钥 - 用于 MCP 服务器的 OAuth 2.1 身份验证。 |
ENABLE_OAUTH_ID_TOKEN_COOKIE | true | 用于向后兼容。控制是否设置旧版的 oauth_id_token cookie。建议设置为 false。 |
ENABLE_OAUTH_TOKEN_EXCHANGE | false | 启用 Token 交换接口,以供外部应用将 OAuth Token 交换为 Open WebUI 的 JWT。 |
ENABLE_OAUTH_BACKCHANNEL_LOGOUT | false | 启用 OIDC 后通道登出端点 (POST /oauth/backchannel-logout),用于由 IdP 发起的登出。需要 Redis 以用于 JWT 撤销。 |
OAUTH_MAX_SESSIONS_PER_USER | 10 | 每个用户、每个提供商的最大并发 OAuth 会话数。防止无限制增长,同时允许在多台设备上使用。 |
关键配置注意事项:
-
必须首先设置 WEBUI_URL:在启用 OAuth 之前,请先在 Admin Panel 中配置
WEBUI_URL,因为重定向 URI 会使用它。 -
持久化配置行为:当
ENABLE_OAUTH_PERSISTENT_CONFIG=true(默认值)时,OAuth 设置在首次启动后将存储在数据库中。如果要在初始设置后修改环境变量,请:- 将
ENABLE_OAUTH_PERSISTENT_CONFIG=false设置为始终从环境变量中读取 - 或者通过 Admin Panel 而非环境变量来更新设置
- 将
-
必填变量:请始终验证您是否使用了与 环境配置文档 中完全一致的变量名称。常见的错误包括使用不存在的变量(如
OIDC_CONFIG)。
服务端 OAuth 会话管理
为了解决与大型 Token 相关的问题(例如,由于 AD FS 用户组 Claim 超过 Cookie 大小限制)并启用自动 Token 刷新,Open WebUI 现在支持健壮的服务端会话管理系统。
工作原理:
- 服务端存储:完整的 Token 载荷不再存储在浏览器 Cookie 中(以避免过大的
access_token和id_token值),而是被加密并安全地存储在 Open WebUI 数据库的新表oauth_session中。 - 安全的会话 Cookie:用户的浏览器只会收到一个很小且安全的
httponlycookie,名为oauth_session_id。该 Cookie 作为一个不透明的标识符,本身不包含任何敏感信息。 - 多设备支持:支持每个用户、每个提供商的多个并发会话。从第二台设备(例如手机)登录不会使第一台设备的会话失效。为了防止会话无限制增长,可配置上限(
OAUTH_MAX_SESSIONS_PER_USER,默认值:10)会在超出时清除最旧的会话。 - 自动 刷新:当下游服务(如 Tool 工具或 OpenAI 兼容端点)需要 Token 时,后端会使用
oauth_session_id来检索 Token。如果 Token 已过期或即将过期,系统会自动使用存储的refresh_token向身份提供商获取新 Token,然后再将其转发。这确保了服务始终能接收到有效的 Token,并防止静默失败。 - 干净的 Token 访问:这种架构为内部工具和其他服务访问用户 Token 提供了一种干净、可靠的方式,而无需依赖脆弱的 Cookie 爬取。
该系统默认启用,但可以通过上面详述的环境变量进行微调。
有关更多信息,请查看 环境变量配置文档页面。
面向外部应用的 OAuth Token 交换
Open WebUI 还支持 OAuth Token 交换,允许外部应用程序通过将 OAuth 提供商的 access token 交换为 Open WebUI 的 JWT 会话 Token,从而在 Open WebUI 中进行身份验证。这对于已经拥有来自身份提供商的 OAuth Token 的脚本、CLI 工具或服务进行程序化访问非常有用。
示例使用场景: 已经从您的身份提供商处获取了 OAuth 访问 Token 的 CLI 工具,可以将其交换为 Open WebUI Token,以便向 Open WebUI 发起 API 调用。
要启用此功能,请设置 ENABLE_OAUTH_TOKEN_EXCHANGE=true。有关使用方法、请求/响应示例以及安全注意事项,请参阅 ENABLE_OAUTH_TOKEN_EXCHANGE 环境变量文档。
OIDC 后通道登出 (Back-Channel Logout)
Open WebUI 支持 OIDC 后通道登出,这允许您的身份提供商 (IdP) 直接通过服务器对服务器通知 Open WebUI 用户登出事件,而无需浏览器重定向。
要启用此功能,请设置 ENABLE_OAUTH_BACKCHANNEL_LOGOUT=true。
启用后,Open WebUI 将暴露:
POST /oauth/backchannel-logout
该接口端点接收由您的 IdP 签发的表单编码的 logout_token,并根据配置的 OAuth/OIDC 提供商元数据和 JWKS 进行验证。
强烈建议并实际上必须配置 Redis,以实现完全的登出强制执行。
- 配置 Redis 后,Open WebUI 将为受影响的用户撤销现有的 JWT,并清除存储的 OAuth 会话。
- 如果没有 Redis,Open WebUI 可以删除存储的 OAuth 会话,但已经签发的 JWT 在过期前仍将保持有效。
有关实现细节和行为说明,请参阅 ENABLE_OAUTH_BACKCHANNEL_LOGOUT。
Google
要配置 Google OAuth 客户端,请参考 Google 官方文档,了解如何为Web 应用程序创建 Google OAuth 客户端。
允许的重定向 URI 应包含 <open-webui>/oauth/google/callback。
需要设置以下环境变量:
GOOGLE_CLIENT_ID- Google OAuth 客户端 IDGOOGLE_CLIENT_SECRET- Google OAuth 客户端密钥OPENID_PROVIDER_URL- 必须设置以使登出正常工作。(通常设置为https://accounts.google.com/.well-known/openid-configuration)
可选的 Google 专属设置:
GOOGLE_OAUTH_AUTHORIZE_PARAMS- 用于传递额外的 Google/authorize参数的 JSON 对象(例如prompt、login_hint、hd)。
GOOGLE_OAUTH_AUTHORIZE_PARAMS={"prompt":"consent","login_hint":"user@example.com","hd":"example.com"}Microsoft
要配置 Microsoft OAuth 客户端,请参考 Microsoft 官方文档,了解如何为Web 应用程序创建 Microsoft OAuth 客户端。
允许的重定向 URI 应包含 <open-webui>/oauth/microsoft/callback。此值应对应 MICROSOFT_REDIRECT_URI 环境变量。
对 Microsoft OAuth 的支持目前仅限于单个租户(Tenant),即单个 Entra 组织或个人 Microsoft 账户。
需要设置以下环境变量:
MICROSOFT_CLIENT_ID- Microsoft OAuth 客户端 IDMICROSOFT_CLIENT_SECRET- Microsoft OAuth 客户端密钥MICROSOFT_CLIENT_TENANT_ID- Microsoft 租户 ID - 个人账户请使用9188040d-6c67-4c5b-b112-36a304b66dadMICROSOFT_REDIRECT_URI- 在您的 Microsoft OAuth 应用程序中配置的重定向 URI。必须设置为<open-webui>/oauth/microsoft/callback。OPENID_PROVIDER_URL- 必须设置以使登出正常工作。
Token 刷新 (offline_access)
默认情况下,Microsoft 的身份平台仅返回 access_token,该 Token 在大约 1 小时后过期。为了实现自动 Token 刷新 —— 避免用户需要重新进行身份验证 —— 请添加 offline_access 作用域 (Scope):
MICROSOFT_OAUTH_SCOPE=openid email profile offline_access
offline_access 作用域会指示 Microsoft 同时返回一个 Refresh Token,Open WebUI 的服务端会话中间件将使用它在 Access Token 过期前自动获取新 Token。
如果没有配置 offline_access,在用户登录超过 1 小时后,您可能会看到重复的日志警告:
WARNING | No refresh token available for session xxx
WARNING | Token refresh failed for user xxx, deleting session
基础的聊天功能(使用 Open WebUI 的 JWT)不会受到影响,但以下功能将会失败:
- 使用
auth_type: "system_oauth"的 MCP 工具服务器 - OneDrive / SharePoint 文件访问
- 来自 Microsoft 的个人资料图片自动刷新
在 Microsoft Entra ID 中不需要进行额外的配置。对于带有客户端密钥的 Web 应用程序,offline_access 作用域是 默认可用 的。
如果您使用 Entra ID 应用角色 (App roles) 来控制在 Open WebUI 中谁能获得 admin 与 user 权限,您还需要配置下面的 OAuth 角色管理。特别要确保在将 ENABLE_OAUTH_ROLE_MANAGEMENT=true 的同时,设置了 OAUTH_ALLOWED_ROLES 和 OAUTH_ADMIN_ROLES —— 否则无论用户在 Entra ID 中被分配了什么角色,他们都会以默认角色创建。
GitHub
要配置 GitHub OAuth 客户端,请参考 GitHub 官方文档,了解如何为Web 应用程序创建 OAuth App 或 GitHub App。
允许的重定向 URI 应包含 <open-webui>/oauth/github/callback。
需要设置以下环境变量:
GITHUB_CLIENT_ID- GitHub OAuth App 客户端 IDGITHUB_CLIENT_SECRET- GitHub OAuth App 客户端密钥
OIDC
可以配置任何支持 OIDC 的身份验证提供商。
需要包含 email Claim。
如果可用,会使用 name 和 picture Claim。
允许的重定向 URI 应包含 <open-webui>/oauth/oidc/callback。
使用以下环境变量:
OAUTH_CLIENT_ID- OIDC 客户端 IDOAUTH_CLIENT_SECRET- OIDC 客户端密钥OPENID_PROVIDER_URL- 必填。 OIDC 发现机制 URL (Well-known URL),例如https://accounts.google.com/.well-known/openid-configurationOAUTH_PROVIDER_NAME- 在 UI 上显示的提供商名称,默认为 SSOOAUTH_SCOPES- 请求的作用域。默认为openid email profileOPENID_REDIRECT_URI- 在您的 OIDC 应用程序中配置的重定向 URI。必须设置为<open-webui>/oauth/oidc/callback。OAUTH_AUDIENCE- 可选的audience值,它将作为附加的查询参数传递给 OAuth 提供商的授权接口。
常见的 OIDC 错误:
- 使用了不存在的环境变量,如
OIDC_CONFIG或WEBUI_OIDC_CLIENT_ID - 忘记设置
OPENID_PROVIDER_URL(这对于 OIDC 是强制性的) - 使用了错误的重定向 URI 格式 - 必须精确为
<your-domain>/oauth/oidc/callback
如果您需要同时支持 Microsoft 和 Google,请查看我们的 双 OAuth 配置教程。
OAuth 角色管理
任何可以配置为在 Access Token 中返回角色的 OAuth 提供商都可以用于管理 Open WebUI 中的角色。
要使用此功能,请将 ENABLE_OAUTH_ROLE_MANAGEMENT 设置为 true。
您可以配置以下环境变量来匹配 OAuth 提供商返回的角色:
OAUTH_ROLES_CLAIM- 包含角色的 Claim。默认为roles。也可以嵌套,例如user.roles。OAUTH_ALLOWED_ROLES- 允许登录的角色的逗号分隔列表(在 Open WebUI 中获得user角色)。OAUTH_ADMIN_ROLES- 允许作为管理员登录的角色的逗号分隔列表(在 Open WebUI 中获得admin角色)。OAUTH_ROLES_SEPARATOR- 允许为OAUTH_*_ROLES变量指定一个替代的分隔符。如果 Claim 是字符串且包含该分隔符,它也将被该分隔符拆分。
如果更改了已登录用户的角色,他们需要退出并重新登录以接收新角色。
OAuth 用户组管理
任何可以配置为在 Access Token 中返回用户组的 OAuth 提供商都可以在用户登录时管理 Open WebUI 中的用户组。
要启用此同步,请将 ENABLE_OAUTH_GROUP_MANAGEMENT 设置为 true。
您可以配置以下环境变量:
OAUTH_GROUP_CLAIM- ID/Access Token 中包含用户所属组的 Claim。默认为groups。也可以嵌套,例如user.memberOf。如果ENABLE_OAUTH_GROUP_MANAGEMENT为 true,则此项必填。ENABLE_OAUTH_GROUP_CREATION- 如果为true(且ENABLE_OAUTH_GROUP_MANAGEMENT也为true),Open WebUI 将执行即时 (Just-in-Time, JIT) 用户组创建。这意味着如果在用户的 OAuth Claim 中存在某个组,但系统中尚未创建,它将在 OAuth 登录期间自动在 Open WebUI 中创建该组。默认值为false。如果为false,则仅管理已存在的 Open WebUI 用户组的成员身份。OAUTH_GROUP_DEFAULT_SHARE- 控制通过 JIT 创建的用户组的默认共享权限。默认值为true(与任何人共享)。设置为members可以将共享范围限制为仅该组成员,或设置为false以完全禁用共享。仅在启用了ENABLE_OAUTH_GROUP_CREATION时生效。
严格的用户组同步
当 ENABLE_OAUTH_GROUP_MANAGEMENT 设置为 true 时,用户在 Open WebUI 中的用户组成员身份在每次登录时与从其 OAuth Claim 中收到的用户组严格同步。
- 用户将被添加到与其 OAuth Claim 匹配的 Open WebUI 组中。
- 如果某些 Open WebUI 组(包括手动创建的或在 Open WebUI 中分配的组)在本次登录会话的 OAuth Claim 中不存在,用户将被从这些组中移除。
请确保在您的 OAuth 提供商中正确配置了所有必需 的用户组,并将其包含在用户组 Claim (OAUTH_GROUP_CLAIM) 中。
管理员用户 管理员用户的用户组成员身份不会通过 OAuth 用户组管理进行自动更新。
更新需要重新登录
如果在 OAuth 提供商中更改了用户的组,他们需要退出 Open WebUI 并重新登录,更改才会生效。
受信请求头 (Trusted Header)
Open WebUI 能够将身份验证委托给一个认证反向代理,该代理会在 HTTP 请求头中传入用户的详细信息。 本页中提供了几个配置示例。
不正确的配置可能会允许用户在您的 Open WebUI 实例上伪装成任意用户进行身份验证。
请确保仅允许认证反向代理访问 Open WebUI,例如不直接向外网暴露容器的任何端口,或者设置 HOST=127.0.0.1 使得服务仅在回环接口上监听。
通用配置
当设置了 WEBUI_AUTH_TRUSTED_EMAIL_HEADER 环境变量时,Open WebUI 会使用该指定请求头的值作为用户的电子邮件地址,处理自动注册和登录。
例如,设置 WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-User-Email 并传入 HTTP 请求头 X-User-Email: example@example.com 会将该请求作为电子邮件 example@example.com 予以认证登录。
(可选)您还可以定义 WEBUI_AUTH_TRUSTED_NAME_HEADER,以确定使用受信请求头创建的任何用户的名称。如果用户已经存在,这不会产生任何影响。
如果未设置 WEBUI_AUTH_TRUSTED_NAME_HEADER,则电子邮件地址将用作用户名。
用户组管理
您可以使用 WEBUI_AUTH_TRUSTED_GROUPS_HEADER 环境变量来同步 Open WebUI 中的用户组。将该变量设置为包含已认证用户以逗号分隔的用户组名称列表的 HTTP 请求头的名称。
当请求通过 WEBUI_AUTH_TRUSTED_EMAIL_HEADER 成功认证,并且受信用户组请求头已设置并存在时,Open WebUI 将更新该用户的组员身份,以与请求头中列出的用户组匹配。
- 请求头的值必须是以逗号分隔的组名列表(例如
X-User-Groups: admins,editors,users)。 - 如果该请求头不存在或为空,则不会更新该用户的组成员身份。
- 用户将被从未在请求头中列出的组中取消分配。
- 通过受信请求头创建组不是自动的;仅会分配 Open WebUI 中已存在的组。
角色管理
您可以使用 WEBUI_AUTH_TRUSTED_ROLE_HEADER 环境变量,通过认证反向代理来控制用户的角色。将该变量设置为包含已认证用户所需角色的 HTTP 请求头的名称。
- 请求头的值必须是
admin、user或pending之一(不区分大小写,已去除首尾空格)。 - 当请求头存在且合法时,每次登录时都会更新用户的角色以匹配请求头的值。
- 如果请求头包含非法值,则不会更改角色并记录一条警告日志。
- 如果请求头不存在或为空,则用户的现有角色保持不变。
配置后,此请求头允许客户端通过 HTTP 请求头设置管理员级访问权限。您必须确保只有您受信任的反向代理或身份提供商可以设置此请求头。允许不受信任的客户端直接访问 Open WebUI 将使任何人都能越权提升为 Admin 权限。这与其他的受信请求头安全模型一致 —— 请参阅本节顶部的警告。
Tailscale Serve
有关涵盖安装、HTTPS、身份验证和 Docker Compose 设置的完整端到端指南,请参阅 Tailscale 集成教程。
Tailscale Serve 允许您在 tailnet 内共享服务,Tailscale 会设置 Tailscale-User-Login 请求头,其中包含请求者的电子邮件地址。
下面是一个示例 Serve 配置以及相应的 Docker Compose 文件,它启动了一个 Tailscale Sidecar,将 Open WebUI 以 open-webui 标签和 open-webui 主机名暴露给 tailnet,并可通过 https://open-webui.TAILNET_NAME.ts.net 进行访问。
您需要创建一个具有设备写入权限的 OAuth 客户端,作为 TS_AUTHKEY 传入 Tailscale 容器。
{
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://open-webui:8080"
}
}
}
}
}---
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
volumes:
- open-webui:/app/backend/data
environment:
- WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Login
- WEBUI_AUTH_TRUSTED_NAME_HEADER=Tailscale-User-Name
restart: unless-stopped
tailscale:
image: tailscale/tailscale:latest
environment:
- TS_AUTH_ONCE=true
- TS_AUTHKEY=${TS_AUTHKEY}
- TS_EXTRA_ARGS=--advertise-tags=tag:open-webui
- TS_SERVE_CONFIG=/config/serve.json
- TS_STATE_DIR=/var/lib/tailscale
- TS_HOSTNAME=open-webui
volumes:
- tailscale:/var/lib/tailscale
- ./tailscale:/config
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: unless-stopped
volumes:
open-webui: {}
tailscale: {}如果您在与 Open WebUI 相同的网络上下文中运行 Tailscale,则默认情况下用户将能够直接访问 Open WebUI,而不经过 Serve 代理。 您需要使用 Tailscale 的 ACL 规则来限制对仅 443 端口的访问。
带有 Cloudflare Access 的 Cloudflare Tunnel
Cloudflare Tunnel 可以与 Cloudflare Access 结合使用,以使用 SSO 保护 Open WebUI。
虽然 Cloudflare 对此几乎没有文档说明,但 Cf-Access-Authenticated-User-Email 被设置为已被认证的用户的电子邮件地址。
下面是一个设置 Cloudflare Sidecar 的示例 Docker Compose 文件。
配置通过仪表盘完成。
从仪表盘中获取 Tunnel Token,将 Tunnel 后端设置为 http://open-webui:8080,并确保勾选并配置了 "Protect with Access"。
---
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
volumes:
- open-webui:/app/backend/data
environment:
- WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email
restart: unless-stopped
cloudflared:
image: cloudflare/cloudflared:latest
environment:
- TUNNEL_TOKEN=${TUNNEL_TOKEN}
command: tunnel run
restart: unless-stopped
volumes:
open-webui: {}oauth2-proxy
oauth2-proxy 是一个身份验证反向代理,实现了主流社交 OAuth 提供商和 OIDC 支持。
鉴于存在大量潜在的配置,下面是使用 Google OAuth 的潜在设置示例。
详细的设置和潜在的安全陷阱请参考 oauth2-proxy 的文档。
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
volumes:
- open-webui:/app/backend/data
environment:
- 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Forwarded-Email'
- 'WEBUI_AUTH_TRUSTED_NAME_HEADER=X-Forwarded-User'
restart: unless-stopped
oauth2-proxy:
image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
environment:
OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180
OAUTH2_PROXY_UPSTREAMS: http://open-webui:8080/
OAUTH2_PROXY_PROVIDER: google
OAUTH2_PROXY_CLIENT_ID: REPLACEME_OAUTH_CLIENT_ID
OAUTH2_PROXY_CLIENT_SECRET: REPLACEME_OAUTH_CLIENT_ID
OAUTH2_PROXY_EMAIL_DOMAINS: REPLACEME_ALLOWED_EMAIL_DOMAINS
OAUTH2_PROXY_REDIRECT_URL: REPLACEME_OAUTH_CALLBACK_URL
OAUTH2_PROXY_COOKIE_SECRET: REPLACEME_COOKIE_SECRET
OAUTH2_PROXY_COOKIE_SECURE: "false"
restart: unless-stopped
ports:
- 4180:4180/tcpAuthentik
要配置 Authentik OAuth 客户端,请参考其集成文档,以了解如何创建应用程序和 OAuth2/OpenID Provider。
允许的重定向 URI 应包含 <open-webui>/oauth/oidc/callback。
在创建提供商时,请记下 App-name、Client-ID 和 Client-Secret,并将其用于 Open WebUI 环境变量:
- 'ENABLE_OAUTH_SIGNUP=true'
- 'OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true'
- 'OAUTH_PROVIDER_NAME=Authentik'
- 'OPENID_PROVIDER_URL=https://<authentik-url>/application/o/<App-name>/.well-known/openid-configuration'
- 'OAUTH_CLIENT_ID=<Client-ID>'
- 'OAUTH_CLIENT_SECRET=<Client-Secret>'
- 'OAUTH_SCOPES=openid email profile'
- 'OPENID_REDIRECT_URI=https://<open-webui>/oauth/oidc/callback'
Authelia
可以配置 Authelia 以返回一个请求头,供受信请求头身份验证使用。 文档可在 这里 找到。
由于部署 Authelia 的复杂性,此处未提供示例配置。