OAuth 2.0 安全最佳实践

本文档介绍了当前 OAuth 2.0 的最佳安全实践。 它更新并扩展了 RFC 6749、6750 和 6819 中给出的威胁模型和安全建议，纳入了自 OAuth 2.0 发布以来收集的实际经验，并涵盖了因 OAuth 2.0 的广泛应用而产生的相关新威胁。 此外，它还废除了一些被认为不太安全甚至不安全的操作模式。

1. Introduction

自 [RFC6749] 和 [RFC6750] 发布以来，OAuth 2.0（本文中简称 "OAuth"）在市场上获得了广泛的关注，并成为 API 保护的标准和使用 OpenID Connect [OpenID.Core] 进行联合登录的基础。 虽然 OAuth 被用于各种场景和不同类型的部署，但仍存在以下挑战：

• OAuth 正被用于比最初考虑的安全要求更高的环境中，如开放银行、电子医疗、电子政务和电子签名。 这些用例需要更严格的准则和额外的保护

• OAuth 在动态设置中的应用远远超出了最初的预期，这给安全性带来了新的挑战。 这些挑战超出了 [RFC6749]、[RFC6750] 和 [RFC6819] 最初的范围。OAuth 最初假定客户端、授权服务器和资源服务器之间存在静态关系。 客户端在部署时就知道服务器的 URL，并为各方之间的信任关系建立了锚点。 客户端是否与合法服务器对话的验证基于 TLS 服务器验证（见 [RFC6819] 第 4.5.4 节）。 随着 OAuth 被越来越多地采用，这种简单的模式逐渐消失，在一些情况下，取而代之的是动态建立客户端与另一端特定部署的授权和资源服务器之间的关系。 这样，同一个客户端就可以访问不同提供商的服务（在标准应用程序接口的情况下，如电子邮件或 OpenID Connect），或在多租户环境中充当特定租户的前端。 OAuth 的扩展（如 OAuth 2.0 动态客户端注册协议 [RFC7591] 和 OAuth 2.0 授权服务器元数据 [RFC8414]）就是为了支持在动态场景中使用 OAuth 而开发的。

• 技术已经发生了变化。 例如，浏览器在重定向请求时处理片段的方式发生了变化，隐式授权的基础安全模型也随之发生了变化。

本文件提供了应对这些挑战的最新安全建议。 它在 OAuth 2.0 [RFC6749] 和 OpenID Connect [OpenID.Core] 等现有规范所定义的要求之外引入了新的要求，并废弃了一些被认为不太安全甚至不安全的操作模式。 不过，本文档并不取代 [RFC6749]、[RFC6750] 和 [RFC6819] 中给出的安全建议，而是对这些文档的补充。

参考资料

Best Current Practice for OAuth 2.0 Security