邮件客户端从基本认证迁移到 OAuth 2.0 该怎么规划？

基本认证（在 SASL 中通常是 PLAIN 或 LOGIN 机制）的模型是：把用户的长期口令原样交给每一个客户端，客户端每次连接都重放这个口令。由此产生四个无法通过加固缓解的结构性缺陷：

• 无法承载多因素：IMAP / SMTP 是无交互界面的协议，没有地方让用户完成第二因素挑战。这导致组织即便部署了 MFA，邮件协议往往成为绕过口——攻击者拿到口令后直接走 IMAP 登录，完全不触发 MFA。
• 无法限定权限范围：口令即全部权限。一个只需要读取收件箱的插件，拿到的是可以收发、可以改配置的完整账户凭据。
• 无法单独吊销：要撤销某一个客户端的访问，只能改口令，代价是所有客户端同时失效。
• 凭据留存面广：口令散落在每台设备、每个第三方应用的配置里，泄露后往往无从追溯是哪一处。

此外，凭据填充与密码喷洒之所以在邮件协议上长期有效，正是因为这里存在一个无 MFA、无验证码、可高频重试的认证端点。

RFC 6749 定义了 OAuth 2.0 授权框架，其核心变化是把「认证」与「授权」分离，并用有生命周期、有范围的令牌取代长期口令：用户在授权服务器上完成认证（此处可以完整实施 MFA、设备合规检查、条件访问策略），客户端拿到的是访问令牌而非口令。

令牌如何进入 IMAP / SMTP 会话，由 RFC 7628 规定——它定义了一组用于 OAuth 的 SASL 机制，使 OAuth 令牌可以在 SASL 框架内承载，从而在现有的邮件协议认证流程中使用，无需改动协议本身。这是整个迁移得以成立的技术支点。

配套的两份最佳实践需要一并纳入设计：RFC 8252（BCP 212）《OAuth 2.0 for Native Apps》规定原生应用应通过系统浏览器而非嵌入式 WebView 完成授权；RFC 9700（BCP 240）《Best Current Practice for OAuth 2.0 Security》（2025 年 1 月）更新了 RFC 6749 等文档，给出当前的 OAuth 安全最佳实践。「用了 OAuth」不等于安全，实现细节错了同样会失陷，这两份文档就是用来约束实现细节的。

1. 盘点：这是决定成败的一步，也是最容易被低估的一步。必须穷举所有仍在使用基本认证的主体，包括：员工使用的桌面与移动客户端及其版本；打印机、扫描仪、监控设备等发送通知的硬件；业务系统的告警与报表发送模块；第三方 CRM、工单、营销平台的收发信集成；运维脚本与定时任务；共享邮箱与功能邮箱。盘点数据只能来自认证日志，不能来自访谈或资产台账。
2. 分类：按客户端类型区分授权模式——有人参与的交互式客户端走授权码流程；无人值守的服务与后台任务走面向机器的客户端凭据类流程，并在授权服务器侧单独建模。
3. 注册与最小授权：为每类客户端单独注册应用标识，按最小必要原则申请权限范围——只读的就不要给发送权限，只需单个邮箱的就不要给全租户权限。这是迁移带来的最大安全收益，若照搬「全权限」则收益近乎为零。
4. 试点：选取覆盖多种客户端与操作系统的小范围用户群，验证首次授权体验、令牌刷新、离线场景与错误提示。
5. 分批切换：按部门或客户端类型分批，每批切换前给出明确的用户指引与回退联系人。
6. 关闭基本认证：先在协议与用户维度做可撤销的分组禁用，观察一个完整业务周期（务必覆盖月末、季末等低频批处理任务），再全局关闭。

• 遗漏非人类账户：绝大多数迁移事故来自打印机、告警脚本、财务系统对账任务这类「没人记得它在发邮件」的主体。它们往往在月末或季末才运行一次，试点期完全观察不到。关闭基本认证前，务必回看至少一个完整月度周期的认证日志。
• 老旧客户端不支持：部分老版本客户端与嵌入式设备根本不支持 OAuth 机制。必须提前决定处置方式——升级、更换、改用其他投递通道（如内网中继），而不是为它们保留基本认证的例外，例外一旦开就很难关闭。
• 把应用专用口令当作终点：应用专用口令绕过了交互式 MFA，本质上仍是长期静态凭据，只是缩小了影响面。它是迁移期的过渡手段，不是目标状态，必须设定明确的清退时间表。
• 授权同意成为新的攻击面：攻击者可以诱导用户为恶意应用授予邮箱读取权限——这类攻击不需要用户口令，且能绕过口令重置。必须开启应用授权审批流程、定期审计已授权应用清单，并把「新出现的高权限邮箱授权」纳入安全监控。
• 忽视令牌本身的价值：刷新令牌一旦泄露，等价于长期凭据。必须依据 RFC 9700 落实令牌绑定、轮换与吊销机制，并确保客户端安全存储。
• 忘了传输层：RFC 8314 明确主张邮件提交与访问不应再使用明文，OAuth 迁移必须与「强制 TLS、禁用明文端口」同步推进。令牌在明文信道上传输，等于换了一种形式的凭据泄露。

用一组可验证的问题来检查迁移是否真正到位，而不是只看「切完了」：

• 能否列出当前所有被授权访问邮箱的应用及其权限范围？
• 能否在不改用户口令的前提下，单独吊销某一个客户端或某一个应用的访问？
• 邮件协议登录是否已完整纳入条件访问与异常检测（地理位置、设备合规、不可能旅行）？
• 基本认证是否已在所有协议维度关闭（IMAP、POP3、SMTP 提交、以及各类管理接口），而非只关了其中一两个？
• 是否存在仍在使用应用专用口令的账户？其清退计划是否有明确日期？

若这些问题不能明确回答，说明迁移只完成了协议替换，尚未完成安全模型的替换。