地址已脱敏。 下文域名、公网 IP、内部端口及应用 Cookie 标识均已脱敏，PORT 不是实际配置值。
来源：本人于 2026-10-06 在本次对话补充的回顾日志。 下文的已验证表示原日志记载有命令、服务状态、浏览器结果或本人确认，不表示本次重新检查了服务器。未给出日内时间的步骤按区间归档，不伪造发生日期。
目标与架构
为 <PASEO_DOMAIN> 建立飞书统一认证，并将 Magpie 从旧 Cloudflare Access 入口迁移到 Authentik。
- Paseo Web UI：aliyun-01。
- Paseo Relay：dmit-vps，公开应用中继地址为
<RELAY_DOMAIN>:443。 - Paseo daemon：原认证日志写
ovh-ovh；与 ovh-dev 的别名对应待核对。 - 统一认证入口：
<AUTH_DOMAIN>。 - 交互验证客户端：Mac mini 上的 Ego Browser。
aliyun-01 的服务检查
检查磁盘与目录分布，分析 /home/xhs 业务数据用途，评估 1Panel。因 OpenResty 与 Docker 仍有依赖，保留相关运行组件，不做无关卸载。
原日志记录 Authentik、PostgreSQL、Worker、Paseo UI 与 OpenResty 服务正常。此处不表示本次再次检查了这些服务。
Paseo 的 Authentik 接入
完成管理员初始化，创建 Application、OAuth2 Provider 和 Proxy Outpost；在 OpenResty 为 <PASEO_DOMAIN> 启用 Forward Auth。
保留原配置备份：/opt/1panel/www/conf.d/paseo-network.conf.bak-authentik。Web UI 可复用服务端已配对的主机；前提是会话、daemon、Relay 和网络均可用，不等于任意原生客户端首次连接不需配对。
Feishu Source 与内部适配器
在飞书开发者后台确认 OAuth 配置，启用 Feishu OAuth Source 并接入 Authentik 默认认证流程。
- 回调地址：
https://<AUTH_DOMAIN>/source/oauth/callback/feishu/。 - 授权接口：
https://open.feishu.cn/open-apis/authen/v1/authorize。 - Token 接口：
https://open.feishu.cn/open-apis/authen/v2/oauth/token。 - 用户资料接口：
https://open.feishu.cn/open-apis/authen/v1/user_info。
在 aliyun-01 部署 authentik-feishu-adapter，端口 PORT，连接 authentik_default Docker 网络，重启策略 unless-stopped，仅供内部调用。
适配器转发授权码与必要客户端字段，兼容飞书顶层 token 返回结构，补充 token_type=Bearer，转换用户资料。Secret 与访问令牌不写入日志或本文。
修复顺序：先补缺失的 redirect_uri，再修顶层 access_token 与 token_type。重建镜像后，原日志记录容器正常。
Paseo 的完整登录结果
原日志记载 Mac mini Ego Browser 完成以下链路：
Paseo 域名 → Authentik Forward Auth → Feishu OAuth
→ token 回调 → 用户资料 → Authentik 会话 → Paseo Web UI最终到达 https://<PASEO_DOMAIN>/，页面标题 Paseo，并能使用已配对主机与 Relay。这个后续结果补充了较早“授权已完成，但连接未确认”的阶段记录；较早记录只描述当时窗口，不作为最终结论。
Magpie 的新入口
在日志所称当前 VPS vps-31c4d433 操作，没有把 aliyun-01 的配置写到另一台设备。
- Magpie 后端从
127.0.0.1:PORT移到127.0.0.1:PORT。 - OAuth2 Proxy 监听 PORT，使用 Authentik 的 Magpie OIDC Provider。
- OIDC issuer：
https://<AUTH_DOMAIN>/application/o/magpie-oidc/。 - 为
<MAGPIE_DOMAIN>增加明确 A 记录指向<PUBLIC_IP>，不再依赖旧服务器的通配符结果。 - Caddy 监听 80/443，提供 Let’s Encrypt HTTPS，再转发到 OAuth2 Proxy。
- 新内部密钥层监听
127.0.0.1:PORT，只在缺少 Magpie Cookie 时注入启动密钥。
最终应用链路：
浏览器 → Caddy HTTPS → OAuth2 Proxy → Authentik / Feishu
↓ 认证后
magpie-key-proxy → MagpieMagpie 的故障与修复顺序
| 阶段 | 当时现象 | 已记录的处理 | 完成边界 |
|---|---|---|---|
| OIDC 流程 | invalid_request |
修正默认认证流程、显式授权流程和 grant types | 授权端点返回正常 302，不是完整登录终态 |
| Token 签名 | failed to verify id token signature |
为 Provider 绑定签名密钥，重启代理刷新 Discovery/JWKS | JWKS 有 RSA 密钥，不等于用户资料已通过 |
| UserInfo | 用户资料接口 403、缺 email claim |
补用户属性映射 | 保存映射不代表已有用户记录自动补字段 |
| 邮箱为空 | email in id_token () isn't verified |
尝试 Feishu Source 映射与 Provider 邮箱声明策略 | 实际邮箱仍为空；最终改为不依赖邮箱 |
| 会话标识 | OAuth2 Proxy 默认依赖邮箱 | 使用 preferred_username，保留 ID Token 校验 |
后端收到的 X-Forwarded-Email 可能是用户标识，不是真实邮箱 |
| 应用层 | 认证出现 AuthSuccess，Magpie 仍返回 401 |
仅本地内部代理补启动密钥 | 首次 303 设置 Cookie，后续带 Cookie 200 |
| 重定向 | 每次请求都带启动密钥造成 303 循环 | 有 Cookie 后不再注入参数 | 避免 ERR_TOO_MANY_REDIRECTS |
未启用 OAUTH2_PROXY_INSECURE_OIDC_ALLOW_UNVERIFIED_EMAIL。会话标识调整不证明真实邮箱已经同步；以后按邮箱限制访问，不能沿用当前 * 域名条件来实现，应另设可见范围、Group 或 Policy。
旧 Cloudflare 入口的停用边界
停止并禁用 cloudflared-paseo.service；原日志记录 Tunnel down、连接数 0。从 Access 的 Paseo 应用移除 <OLD_MAGPIE_DOMAIN>，仍保留 <OLD_PASEO_DOMAIN> 配置。
Tunnel 和 Access 应用没有永久删除。永久删除超出当时“停止”的授权，被审批拦截。旧域名的 Error 1033 与停用 Tunnel 对应，不能解释为新 Magpie 入口故障。
最后确认与仍未解决的字段
原日志记载 OAuth2 Proxy、内部密钥代理和 Caddy 运行；Mac mini Ego Browser 已加载 Magpie 页面，资源与 API 返回 200。本人最后确认 <MAGPIE_DOMAIN> 可正常打开并完成飞书登录。
因此 Magpie 的最终状态记录为 本人确认可用，并有原日志所载浏览器结果。早期 DNS 缓存与登录待验证状态不再作为最终结论。真实 Feishu 邮箱字段仍为空，不能被后续登录成功覆盖为“邮箱同步已修复”。