issue: MCP OAuth callback fails with a CSRF state mismatch because the owui-session cookie is never stored in the browser

在 Open WebUI 上通过 MCP OAuth 2.1(例如 Google Workspace MCP)完成 Google 登录、被重定向回 Open WebUI 回调时,如果浏览器从未存下 owui-session cookie,会话里的 state 就无法在回调阶段取回,于是抛出 issu

快速结论:在 Open WebUI 上通过 MCP OAuth 2.1(例如 Google Workspace MCP)完成 Google 登录、被重定向回 Open WebUI 回调时,如果浏览器从未存下 owui-session cookie,会话里的 state 就无法在回调阶段取回,于是抛出 issues: MCP OAuth callback fails with a CSRF state mismatch because the owui-session cookie is never stored in the browser。优先排查会话 cookie 是否被浏览器拒收,而不是 MCP 连接本身。

适用环境:Open WebUI v0.9.6(Git Clone 方式安装)、Ubuntu 24.04 LTS、Docker 部署、Caddy TLS 反向代理、浏览器为 Chrome 143.0.7499.147 与 Brave 1.91.168;已设置 WEBUI_SECRET_KEY、REDIS_URL=redis://172.17.0.5:6379、WEBUI_SESSION_COOKIE_SAME_SITE=lax、WEBUI_SESSION_COOKIE_SECURE=true;MCP 侧使用 taylorwilsdon/google_workspace_mcp(Streamable HTTP、OAuth 2.1 Static),mcpo 配置正常,GitHub MCP 与 Mem0 连接正常。

最快修复方案:暂无确认的一步修复方案。Issue 中给出的两个可能原因(Starlette SessionMiddleware 生成的 base64 cookie 含 + / = 违反 RFC 6265 而被严格浏览器拒收、以及会话状态写读路径问题)尚未在该 Issue 中验证。

注意事项:Issue 中只完成了现象定位与推测,未提供已验证的修复补丁或配置项;因此不要把任何命令、镜像版本或环境变量当作官方修复操作。排查时不要为了绕过问题而关闭 WEBUI_SESSION_COOKIE_SECURE,那会引入新的安全问题。

问题场景

用户在 Open WebUI 聊天会话中启用 Google Workspace 工具(MCP 连接),该工具使用 MCP OAuth 2.1(Static)并配置了 taylorwilsdon/google_workspace_mcp 作为 Streamable HTTP MCP,OAuth Server URL 指向 workspace-mcp 地址,并通过 DCR 获取 client ID/secret。点击激活后浏览器跳转到 Google OAuth 完成登录,Google 再重定向回 Open WebUI 的 OAuth 回调地址,此时回调处理失败并报 CSRF state 不匹配。同一环境下 mcpo/GitHub 与 Mem0 等其他 MCP 连接工作正常,说明不是通用 MCP 连通性问题。

报错原文

OAuth callback failed: mismatching_state: CSRF Warning! State not equal in request and response.

Issue 标题对应的核心报错为:

issue: MCP OAuth callback fails with a CSRF state mismatch because the owui-session cookie is never stored in the browser

原因分析

根据 Issue 作者调试得出的结论,MCP OAuth 的 state 值在发起授权时被写入服务端会话(owui-session),回调时需要从同一个会话 cookie 中读回并比对。问题出在浏览器侧从未保存该 cookie,导致回调阶段找不到对应的 state,于是报 mismatching_state。

可能原因(Issue 中列出的推测,尚未确认):

  • Starlette SessionMiddleware 把会话编码为 base64,生成的 cookie 值可能包含 +、/、= 等字符,违反 RFC 6265;严格实现的浏览器可能直接拒收该 cookie,使 state 在回调时无法恢复。
  • 会话 cookie 的写/读路径或作用域在反向代理(Caddy TLS)与 Docker 部署组合下不一致,导致 Set-Cookie 未真正落到浏览器。

环境排查

  • 确认 Open WebUI 版本为 v0.9.6(Git Clone 安装),或与 Issue 环境一致后再复现。
  • 确认浏览器为 Chrome 143.0.7499.147 / Brave 1.91.168,或换用其他浏览器交叉对比 cookie 是否被拒收。
  • 确认部署方式为 Docker,前置 Caddy TLS 反向代理,并核对代理是否透传 Set-Cookie(包括 Domain、Path、Secure、SameSite 属性)。
  • 确认已设置 WEBUI_SECRET_KEY、REDIS_URL=redis://172.17.0.5:6379、WEBUI_SESSION_COOKIE_SAME_SITE=lax、WEBUI_SESSION_COOKIE_SECURE=true。
  • 确认 MCP 配置为 Streamable HTTP + OAuth 2.1(Static),OAuth Server URL 指向 workspace-mcp,且已通过 DCR 获取 client ID/secret。
  • 确认 mcpo、GitHub MCP、Mem0 连接正常,用来排除通用 MCP 连通性问题。

解决步骤

  1. 先确认问题边界:在同一浏览器中打开开发者工具的 Application/Storage → Cookies,检查访问 Open WebUI 域名后是否出现 owui-session;如果始终没有该 cookie,则与 Issue 描述一致。
  2. 查看响应头中的 Set-Cookie,检查 owui-session 的值是否包含 +、/、= 等字符,以及 Secure、SameSite、Domain、Path 是否符合当前 HTTPS 访问方式。
  3. 确认 Caddy 或其他反向代理没有剥离、重写或缓存 Set-Cookie 头;对比直连 Open WebUI 端口与经 Caddy 访问时 cookie 是否都出现。
  4. 在复现 OAuth 流程时,对照浏览器控制台、网络面板与服务端日志中的 state 值,确认发起授权时写入的 state 与回调返回的 state 是否一致。
  5. 由于该 Issue 已关闭但未收录明确修复代码,建议对照仓库中与 OAuth/MCP 会话处理相关的后续改动或 PR(例如评论中提到的 https://github.com/open-webui/open-webui/pull/31894),确认是否已包含 cookie 编码/会话状态处理修复;如有,升级到包含该修复的版本后重试。
  6. 如果只是需要临时绕过,可优先尝试换一个对 cookie 值更宽松的浏览器(如 Firefox)验证是否为浏览器拒收 cookie 所致,但这只是定位手段,不是正式修复。

验证方法

在浏览器中确认 owui-session cookie 已被正常存储,并且其值符合 RFC 6265(不含未编码的 +、/、=);随后重新发起 Google Workspace 工具的 OAuth 授权,完成 Google 登录后不再出现 mismatching_state: CSRF Warning! State not equal in request and response.,并能正常进入 Google Workspace 内容访问流程,即视为问题解决。

参考来源

open-webui/open-webui #26382

GamsGo AI

AI 工具推荐

想把多个 AI 模型放在一个入口?

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 27288

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注