RFC 7628《面向 OAuth 的一组 SASL 机制（OAUTHBEARER / OAUTH10A）》中文导读

IETF · RFC 7628 · 标准跟踪（Standards Track） · 2015 年 8 月

诚实披露：本页为 IETF RFC 7628 的中文译介版本。原文由 IETF 发布，依 IETF Trust 条款可自由再制与翻译；本译本由 AI 基于人类权威一手文献（RFC 英文原文）辅助整理生成，非人类原创，亦非逐字全文翻译，仅供学习参考。任何规范性判断以英文原文为准，英文原文见 rfc-editor.org/rfc/rfc7628.txt。

摘要

OAuth 最初是为 HTTP 设计的授权框架，而邮件世界的核心协议 IMAP、SMTP、POP 并非基于 HTTP。RFC 7628 通过 SASL（Simple Authentication and Security Layer，简单认证与安全层）框架搭桥，定义了两种机制——OAUTHBEARER（承载令牌，对应 OAuth 2.0 Bearer Token）与 OAUTH10A（对应 OAuth 1.0a 的 HMAC-SHA1 密钥消息摘要）——使非 HTTP 应用协议也能直接携带 OAuth 凭据完成认证。

这份文档是今日「用 Microsoft 365 / Google Workspace 账号以现代认证方式登录 IMAP/SMTP」的规范基础，也是各大邮件服务商淘汰基础认证（Basic Auth）后所依赖的标准之一。

1-2. 引言与术语

SASL 是一套被广泛复用的认证框架，IMAP、SMTP、POP、XMPP、LDAP 等协议都通过它插接具体的认证机制。本文档所做的，就是把「OAuth 令牌」这一凭据类型注册为 SASL 机制，从而无需为每个应用协议单独设计 OAuth 绑定方式。术语沿用 OAuth 与 SASL 既有定义。

3. OAuth SASL 机制规范

需要首先明确一条能力边界：

"SASL mechanisms using this document as their definition do not provide a data security layer; that is, they cannot provide integrity or confidentiality protection for application messages after the initial authentication."（§3）

译：以本文档为定义的 SASL 机制不提供数据安全层；也就是说，它们无法在初始认证之后为应用消息提供完整性或机密性保护。

因此传输层保护必须由 TLS 承担：OAUTHBEARER 必须（MUST）使用 TLS 来保护 bearer token（令牌一旦泄露即可被直接重放）；OAUTH10A 因使用 HMAC-SHA1 密钥摘要而风险略低，但仍推荐（RECOMMENDED）使用 TLS。

3.1 客户端初始响应

客户端的初始响应结构为：gs2-header + 分隔符 %x01（记作 ^A）+ 零个或多个 key=value^A 键值对 + 结尾分隔符。主要键：

键要求说明
authREQUIRED相当于 HTTP 中 Authorization 头的负载，例如 Bearer <token>
hostOAUTH10A 必需客户端所连接的主机名
portOAUTH10A 必需客户端所连接的十进制端口

OAUTHBEARER 下 host/port 为可选，但原文示例中均予携带（服务端可据此做绑定校验）。gs2-header 中可携带 authzid（授权身份，即用户名），形如 n,a=user@example.com,。

关于「只含一个分隔符」的特殊响应：

"The client response consisting of only a single kvsep is used only when authentication fails and is only valid in that context."（§3.1）

译：仅由单个 kvsep 构成的客户端响应，只在认证失败的场景下使用，且仅在该上下文中有效。

需要说明，文档指出 gs2-header 规则在此仅作为「与 GS2 兼容的占位」，本文档并未真正定义 GS2 机制。

3.2 服务端响应与错误发现

认证成功时服务端按各应用协议的常规方式返回成功。认证失败时：

"For a failed authentication, the server returns an error result in JSON [RFC7159] format and fails the authentication."（§3.2.2）

译：认证失败时，服务端以 JSON 格式返回一个错误结果，并使本次认证失败。

该 JSON 的字段包括：

这实际上构成了一条轻量发现通道：客户端拿着令牌来，服务端告诉它「你的 scope 不对」或「去这个地址取配置」。收到错误后，客户端必须发送单个 ^A（Base64 编码即 AQ==）或使用应用协议自身的中止方式（IMAP 中为 *）来干净地结束这次 SASL 交换（§3.2.3）。

3.3 使用密钥消息摘要的令牌类型

该节针对 OAUTH10A 一类基于 HMAC 的访问令牌，说明其签名基串构造需要 host 与 port 参与，这也是这两个键在 OAUTH10A 下被要求必填的原因。

4. 示例与在 IMAP / SMTP / POP 上的应用

原文第 4 节给出多组完整交换示例：IMAP 使用 SASL-IR 在 AUTHENTICATE 命令中直接携带 Base64 编码的初始响应；SMTP 则在完成 TLS 协商后使用 AUTH OAUTHBEARER。解码后的初始响应形态大致为：

n,a=user@example.com,^Ahost=server.example.com^Aport=143^Aauth=Bearer <access_token>^A^A

其中 ^A 即 %x01。POP 未单独举例，但 POP 支持 SASL，同样适用本机制。

5. 安全考量

6-7. 国际化与 IANA

国际化方面主要涉及 authzid 中用户名的处理。IANA 侧完成了 OAUTHBEARER 与 OAUTH10A 两个 SASL 机制名的注册。

参考链接