Salesloft 数据泄露：PKI 如何降低 OAuth 令牌劫持风险

简介

证书，尤其是 mTLS（Mutual TLS）证书，是降低 OAuth 令牌被盗后风险的有效机制。它们无法阻止令牌本身被盗，但能大幅限制攻击者利用被盗令牌的能力。

核心思路是通过密码密钥对将 OAuth 令牌绑定到特定客户端，使被盗令牌无法在其他客户端上使用。

核心问题：OAuth 令牌被盗

1. 窃取：攻击者窃取访问令牌，例如通过中间人攻击、日志泄露、浏览器缓存被攻破或恶意扩展程序。
2. 重用：攻击者将被盗令牌提交给资源服务器（例如 API）。
3. 获得访问权限：资源服务器验证令牌签名和有效期，但无法判断请求是否来自合法客户端，因此攻击者可能获得未授权访问。

解决方案：基于证书的客户端身份验证 (mTLS)

此方法采用 OAuth 2.0 Mutual-TLS Client Authentication 和 Certificate-Bound Access Tokens 规范，分为两个主要部分。

第一部分：使用证书验证客户端

客户端请求令牌时，通过 TLS 证书证明身份，而不是只依赖 client_id 和 client_secret。

1. 客户端配置：为合法客户端应用配置唯一的 X.509 证书及其私钥。在企业环境中，此过程可以动态完成。
2. TLS 握手：客户端连接授权服务器请求令牌时，会执行完整的 mTLS handshake。服务器像标准 TLS 一样向客户端证明身份；客户端也必须出示证书并使用私钥签署数据，以向服务器证明身份。
3. 令牌请求：客户端发起标准令牌请求（例如使用 client_credentials 授权或授权码）。授权服务器依据成功的 mTLS handshake 验证客户端身份，而不是依赖共享密钥。

第二部分：将令牌绑定到证书（关键步骤）

1. 计算指纹：授权服务器计算 mTLS 握手中所提交证书的指纹。常见方法是对证书的 DER 编码计算 SHA-256 hash。
2. 将指纹写入令牌：授权服务器将证书指纹（x5t#S256）直接嵌入访问令牌，例如作为 JWT claim。
3. 使用令牌：客户端调用 API（资源服务器）时，必须再次执行 mTLS handshake，并出示获取令牌时使用的同一张证书。
4. 资源服务器验证令牌：服务器照常验证令牌签名和有效期，提取令牌中的证书指纹，计算 TLS 握手中客户端证书的指纹并比较两者。指纹匹配则允许请求，不匹配则拒绝。

如何限制令牌被盗造成的影响

1. 攻击者窃取令牌，并尝试从自己的设备向资源服务器使用该令牌。
2. 资源服务器要求进行 mTLS handshake，但攻击者没有与合法客户端证书对应的私钥。
3. 攻击者无法完成 mTLS 握手；连接会在 TLS 层终止，令牌甚至不会被发送。
4. 即使攻击者设法发送令牌，服务器也会发现客户端证书缺失，或证书指纹与令牌中的指纹不匹配。
5. 请求会被拒绝。没有对应证书和私钥，被盗令牌无法单独使用。

标准与配置文件

这不是专有方案，而是由 IETF 标准定义：

• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens：核心规范。
• FAPI 2.0 Security Profile：在高安全场景中强烈推荐并采用基于 mTLS 的客户端身份验证和令牌绑定。

优势

1. 强身份验证：使用强密码学证明取代静态 client_secret。
2. 缓解令牌重放：只有持有令牌绑定证书的客户端才能使用该令牌。
3. 纵深防御：即使其他措施（例如令牌存储）失效，仍可提供保护。

挑战与注意事项

1. 复杂性：客户端证书的签发、轮换和撤销比管理密钥更复杂。公钥基础设施 (PKI) 及 PKI Trust Manager 等 CLM 解决方案可简化 mTLS 证书管理。
2. 客户端支持：并非所有 OAuth 客户端库和应用都原生支持 mTLS 和证书呈递。
3. 部署工作：需要配置授权服务器、资源服务器和所有客户端。

总结

总之，使用 mTLS 证书验证客户端并将令牌绑定到证书，是缓解 OAuth 令牌被盗风险的有效策略。它将安全模型从“持有令牌”提升为“持有令牌及对应的密码密钥”，显著提高攻击者的难度。此方法适用于保护机器对机器 (M2M) 通信和高价值 API，包括 AI agents。