通过 FAPI 2.0 加强 OAuth 2.0
Source: Dev.to
OAuth 2.0 长期以来一直是现代授权的基石，为社交登录到复杂的企业集成提供动力。它的灵活性使开发者能够将该框架适配到各种场景，如传统 Web 应用、单页应用（SPA）、桌面和移动环境。
Vanilla OAuth 2.0 的挑战
由于 OAuth 2.0 是一个框架而非刚性的协议，它提供了一系列可选特性。在高风险和受监管的行业——银行、医疗、保险——这种自由度会导致大量配置错误和互操作性问题的风险面。安全漏洞往往不是单个规范本身的缺陷，而是它们的组合方式导致的（例如，在没有 PKCE 或使用不安全的重定向 URI 的情况下使用授权码流程）。
引入 FAPI 2.0 配置文件
FAPI 2.0 是由 OpenID Foundation 制定的安全配置文件。与其前身不同，它强调简洁性和强大的互操作性。它 不是 新的协议；而是一个规定性配置文件，明确指出必须使用哪些 OAuth 2.0 和 OpenID Connect 扩展以及如何进行配置。
关键特性
- 基于正式的攻击者模型，假设高威胁环境（网络被控制、前通道拦截）。
- 强制“默认安全”姿态，去除可选的安全最佳实践。
- 提供针对现代攻击向量（如会话注入、令牌窃取和授权请求篡改）的标准化抗性水平。
核心安全增强
FAPI 2.0 在三个主要方面强化 OAuth 2.0：加固授权请求、消除持有者令牌风险以及改进客户端认证。
推送授权请求（PAR）
FAPI 2.0 强制要求。
客户端通过安全的后端 POST 请求在重定向前发送授权参数（作用域、PKCE 挑战等）。服务器返回一个短期有效的 request_uri，在随后的浏览器重定向中使用，从而确保敏感数据永不出现在浏览器历史或日志中。
受限发送者令牌
FAPI 2.0 用与客户端加密绑定的令牌取代易受攻击的持有者令牌：
- 相互 TLS（mTLS）： 将令牌绑定到客户端的 X.509 证书。
- 拥有权证明（DPoP）： 一种应用层方案，客户端为每个请求使用私钥对 JWT 进行签名。
即使令牌被窃取，这些机制也能防止其被滥用。
非对称客户端认证
共享的客户端密钥被非对称认证取代，通常使用 Private Key JWT：
- 客户端使用其私钥对 JWT 进行签名。
- 授权服务器使用客户端注册的公钥验证签名。
这样就消除了在传输过程中泄露客户端密钥的风险。
FAPI 认证的作用
OpenID Foundation 的认证计划提供自动化测试，以验证是否符合 FAPI 配置文件。获得认证的组件：
- 减少安全审计的工作负担。
- 确保互操作性——任何供应商的 FAPI‑兼容客户端都能与 FAPI‑兼容的授权服务器无缝协作。
选择经过认证的实现可确保系统遵循业界领先的安全标准。
进一步阅读
- OpenID FAPI 2.0 Security Profile – Final Specification
- OAuth 2.0 Pushed Authorization Requests (RFC 9126)
- OAuth 2.0 Demonstration of Proof‑of‑Possession (RFC 9449)
- FAPI 2.0 Attacker Model
想要面向开发者的概览，请参阅免费电子书 A Developer’s Guide to FAPI，其中详细说明了使您的应用程序符合 FAPI 要求的安全措施。