问题
自托管爱好者用 Ollama + Open WebUI 搭建本地 AI 服务并暴露到公网以远程访问，但 Open WebUI 缺少基本的 TOTP 二步验证。用户在 issue 中写道："I looked through the Web UI settings looking to set up a 2FA device and realized that such setting does not exit, not even for a simple TOTP." 目前只能靠反向代理层挡住流量、强制先经过本地 OIDC 提供商认证，但这会破坏移动客户端集成并要求双重认证，体验割裂。
目标用户
用 Ollama + Open WebUI 自托管 LLM 并暴露到公网远程访问的技术爱好者 / self-hoster。单个 issue 有 46 条评论，说明这是一个真实且有一定共鸣的痛点群体，但整体属于小众极客市场。
解决方案
- 一键部署的认证网关：Docker 容器形式部署在 Open WebUI 之前，自动拦截所有未认证请求
- TOTP 二步验证：网页端扫码绑定验证器 App，完成验证后放行会话
- 移动端友好直连：对 Open WebUI 移动客户端使用的 API 路径做 token 直连放行，避免双重登录
- AI 角色有限：这是一个传统安全中间件产品，AI 仅体现在目标场景（保护自托管 LLM 服务）上，可用 LLM 辅助生成部署配置向导降低上手门槛
为什么是现在
自托管 LLM（Ollama + Open WebUI）在 2024 年成为流行玩法，越来越多非企业用户把实例暴露到公网做远程访问，安全问题随之暴露——信号中的 issue 正是 2024 年 3 月提出的，且引发 46 条讨论，说明用户基数和风险意识在同步增长。
MVP 范围
做什么：
- 一个 Docker 一键部署的认证网关（sidecar / 反向代理插件形式），部署在 Open WebUI 前面
- Web UI 引导用户完成 TOTP 设备绑定与验证
- 兼容移动客户端的直连 API 路径放行策略，避免信号中提到的双重认证问题
不做什么：
- 不做多租户、企业 SSO、完整 IAM
- 不做除 Open WebUI（及 Ollama API）之外的其他应用的统一认证
- 不修改 Open WebUI 本身代码，只做外挂层
风险
- 上游修复风险：Open WebUI 官方一旦内置 2FA，外挂方案即失去存在意义，这是最大的平台依赖风险
- 付费意愿低：信号明确显示该群体 willingness_to_pay: none，更可能期望开源免费方案
- 多样部署环境：自托管用户的网络拓扑（反代、VPN、Docker、裸机）高度异构，兼容性支持成本高
- 安全责任：认证网关自身成为攻击面，一旦出漏洞后果严重，小团队维护安全组件压力较大
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
GitHub Issues · open-webui/open-webui3月20日投资方向▲ 6546 条评论
“I looked through the Web UI settings looking to set up a 2FA device and realized that such setting does not exit, not even for a simple TOTP.”
Open WebUI lacks TOTP 2FA support even when the instance is exposed to the internet.原文