来源：本人补充的认证工作日志。 修复与结果是历史记录，本次没有修改 Provider、权限或信任策略。
授权码与 Token 格式
首次缺 redirect_uri；后续缺 token_type 和 access_token。原日志确认飞书 Token 字段在顶层，不在通用处理器预期的 data 对象内。
内部适配器补回调地址、兼容实际返回结构并补 Bearer 类型。不能仅凭“OIDC 兼容”推定所有字段已经符合通用客户端预期。
Provider 流程与签名
invalid_request 对应错误的认证/授权流程与空 grant types。流程修复后的 302 只证明授权入口正常。
failed to verify id token signature 对应日志中的空 signing_key 与空 JWKS。绑定签名密钥、重启代理刷新发现信息后，签名阶段通过；不能把它写成完整登录已经通过。
用户资料与邮箱
原日志随后记录 UserInfo 403、邮箱 claim 为空和未标 verified。飞书权限开通、Source 映射保存以及重新授权不保证已有用户记录已经获得邮箱，需检查实际返回与存储结果。
曾讨论并配置服务专用邮箱验证声明，最终会话采用 preferred_username。因此最终事实是“登录会话可建立”，不是“真实邮箱已经同步”或“所有用户邮箱都已核验”。
会话主体与授权边界
稳定身份标识可以满足不需要邮箱的服务；若后端 X-Forwarded-Email 实际携带用户标识，不能继续把它当邮箱使用。
未开启不安全的未验证邮箱绕过，保留签名验证。需要限制访问范围时，在飞书应用可见范围、Authentik Group 或 Policy 中明确设置，不把 OAUTH2_PROXY_EMAIL_DOMAINS=* 当成邮箱白名单。