摘要

  • RFC 4422 将“凭据证明了谁”与“客户端请求以谁的身份行事”分开；服务器既要验证凭据，也要单独验证这层代行关系。
  • SASL 成功可以建立会话身份或启用协商后的安全层，却不会自动决定应用中的每项操作、资源与权限。

绿色结果究竟回答了什么

认证界面常把复杂过程压成一个勾。对使用者来说，这很清楚；对日志和事故分析来说，却容易把多项判断揉成一句“用户已获准”。凭据是否有效、某个主体能否以另一个身份行事、服务是否愿意接纳这次会话、具体资源是否允许访问，本来就是不同问题。

SASL 处在面向连接的应用协议与可替换认证机制之间。机制负责凭据交换与证明方法，应用协议的 SASL 配置则负责承载消息、解释身份并改变协议状态。这样的分工让旧协议能够使用新机制，也让同一机制服务不同协议；它没有赋予机制理解所有业务权限的能力。

因此，成功结果可以非常真实，却仍然很窄。它可能意味着服务器接受了这次身份关系，也可能意味着接下来的字节将受到协商安全层保护。它不等于所有邮箱、命令、数据集或管理入口都已开放。随后出现拒绝，可能恰恰说明系统没有把认证冒充成授权。

一个交换里藏着两个身份

RFC 4422 的关键切口，是认证身份与授权身份。认证身份和凭据相连：密码、证书、票据或其他材料所对应的主体。授权身份则是客户端希望“以其名义行事”的主体。

日常登录中，两者往往相同，所以第二个身份很容易被忽略。客户端不提交授权身份字符串时，相当于请求以服务器从凭据中关联出的身份行事。可是在代理或委托场景里，A 可以先证明自己是 A，再请求以 B 的身份操作。

服务器于是必须完成两次性质不同的核验。先验证凭据，并确定认证身份；再判断这个身份是否可以代行所请求的授权身份。任何一步失败，SASL 交换都应失败。有效凭据不能因为能够拼出另一个名字，就自动成为委托凭证。

即便 B 被接受，也不能把“授权身份”理解成跨系统通行的角色包。它只是进入该应用协议授权状态的身份。B 能否读取某个对象、执行某条命令、超过某项配额，仍要由具体的资源规则决定。

应用配置必须补完语义

SASL 没有假装所有协议共用一种身份模型。RFC 4422 要求采用者说明机制如何发现和选择、挑战与响应如何传送、非空授权身份采用什么语法和含义、安全层从哪个字节开始、多层保护如何排序，以及多次认证会怎样改变已有状态。

这些要求标出了可替换性的边缘。机制可以升级，而不用重写应用消息；应用可以保留自己的资源语义，而不用把它塞进每种密码算法。但如果实施者没有明确这条接缝，两个团队就会互相假定“另一层已经做过授权”。

线上的身份字符串还可能经过本地规范化、目录映射、组关系计算与策略求值。一次无可挑剔的 SASL 记录，只能证明交换本身满足条件，不能证明这些本地映射没有过期、歧义或范围过宽。

SMTP 的 235 只属于 AUTH

SMTP AUTH 提供了一个边界清晰的例子。RFC 4954 把 235 2.7.0 Authentication Succeeded 定义为 AUTH 命令的成功响应，并把一个授权身份关联到 SMTP 会话。它准确描述了那条命令和那段会话，并不是随后邮件事务的收据。

如果 AUTH 协商出安全层，SMTP 还会重置到初始状态。客户端与服务器丢弃先前获取的能力信息，客户端应再次发送 EHLO。认证的绿色结果并非对话终点，反而可能开启一次按规则重建的应用状态。

中继许可、收件人检查、内容策略、排队与最终投递都有自己的决定。这里借用 SMTP，不是重复讨论“接收并非送达”，而是观察一个更窄的事实：明确的成功码也必须带着它所回答的命令来读。

SASL 也可以成功地不证明任何人

RFC 4505 的 ANONYMOUS 机制把这个问题推到最明显处。它允许用户在不建立或披露身份的情况下获得通常受限的访问。可选的追踪字符串没有经过认证，而且可以伪造。

所以，日志里同时出现 SASL、某个机制名和成功状态，仍不足以写成“身份已核实”。分析者必须先问机制承诺证明什么、是否建立身份，以及应用附加了哪些限制。把匿名交换归入“已验证用户”，是在日志层制造标准从未提供的证据。

更强的证明不会替你写权限表

RFC 7677 后来登记了 SCRAM-SHA-256 与 SCRAM-SHA-256-PLUS。SHA-256 和相关信道绑定要求强化了可替换的认证环节。这是实质安全改进，却仍不知道某个邮箱、目录或命令属于谁。

升级机制可以降低凭据暴露、重放或信道混淆风险，却修不好过宽的组成员关系、已经失效的代行规则，或者把会话身份直接当作资源许可的应用。密码学保证与授权正确性会在决策点相遇，但不能互相代替。

为每一次判断留下不同证据

发生争议操作时，可用记录至少应区分：选择了什么机制、是否使用信道绑定或安全层、服务器映射出的认证身份、客户端请求的授权身份、最终接受的身份、允许代行的策略，以及后来针对资源作出的决定。

若系统只保存一个“用户”字段，凭据被盗、委托过宽、目录映射滞后和应用权限错误就可能呈现为同一条日志。一个成功位足够推动协议状态机，却远远不足以重建责任链。

界面语言也应保持克制。“已以某身份登录”描述会话；“可以修改此对象”则宣告对具体操作完成了授权。把两句话合为一枚通用勾，只会让合法拒绝显得像故障，也把真正掌握资源控制权的组件藏起来。

来源