FAPI 2.0 深度解析：下一代金融级 API 安全标准与实践指南

金融级API安全配置文件（FAPI）1.0已经是最终版本，并被广泛应用于许多实现中。在1.0版本最终确定的同时，FAPI 2.0的设计工作也随之启动。与1.0版本相比，FAPI 2.0采用了不同的设计思路，重点在于通过攻击者模型定义潜在威胁和安全目标，而不是简单地划分基线和高级配置文件的级别。

攻击者模型：FAPI 2.0的安全目标基础

FAPI 2.0引入了攻击者模型，用于明确安全目标，并识别需要防范的潜在攻击者类型。这一模型的设计旨在为其他配置文件提供参考，使其能够轻松引用这些攻击者和目标，从而确保文档符合安全要求。此外，攻击者模型还可用于API平台的正式安全分析，进一步提升整体安全性。

基线安全：FAPI 2.0的核心配置文件

FAPI 2.0的安全配置文件可视为其基线，建议使用多种OpenID规范来防御攻击者模型中定义的威胁。该配置文件涵盖了角色要求、安全考虑、网络层保护以及加密算法等主题。

通过参考攻击者模型，安全配置文件明确了已知的敏感区域及其防护措施。这些案例和缓解方案均基于攻击者模型中的定义。对于服务器和客户端角色，配置文件详细列出了需要实现的流程，以确保符合安全要求。尽管FAPI 1.0中的一些内容得以保留，但许多要求已被替换为新技术。例如，拨款管理和丰富授权请求（RAR）在FAPI 2.0中被列为建议，而非强制要求。

FAPI 1.0与2.0的关键区别

仅代码流

在FAPI 2.0中，混合流被移除，仅支持response_type=code。这意味着所有令牌都通过后端通道传递，从而无需加密id_tokens。这一变化显著降低了客户端的复杂性，因为前端通道中获取id_token需要额外的验证步骤。现在，诸如“nonce”、“s_hash”和“at_hash”等验证已被移除。

标准杆数和PKCE

在FAPI 1.0中，“id_token”用于验证响应的完整性和来源。而在FAPI 2.0中，使用PKCE和代码流确保令牌通过TLS传递，进一步提高了安全性。通过PKCE，可以验证请求是否来自同一来源，从而提供一定的CSRF保护。如果您的用例需要消息完整性，建议使用消息签名配置文件中的JAR/JARM。

发送方约束令牌

FAPI 2.0进一步提升了令牌的安全性，通过发送方约束令牌确保令牌仅能被指定的接收方使用。

高级配置文件：消息签名

消息签名配置文件是FAPI 2.0的高级配置文件，旨在满足攻击者模型中的所有安全目标，并实现消息类型的不可否认性。与安全配置文件不同，消息签名配置文件是独立的，实施者需根据需求选择适合的配置文件。

该配置文件详细描述了如何使用现有规范实现安全目标。例如，授权请求和响应可通过标准杆数/JAR/JARM系列进行签名。此外，HTTP消息签名规范被用于对资源请求和响应进行签名，从而在客户端和资源服务器之间实现不可否认性。

实施建议：提升FAPI 2.0的实用性

FAPI 2.0的实施建议文件目前仍在开发中，旨在为平台实施提供指导。例如，建议在请求中添加“x-fapi-interaction-id”标头，以便跨服务跟踪相同的交互。尽管这些建议并非基线要求，但它们为开发者提供了额外的优化方向。

总结

FAPI 2.0的开发工作正在稳步推进，未解决的问题逐渐减少，目标逐步实现。Curity团队密切关注FAPI 2.0的进展，并积极参与相关工作。目前，Curity Identity Server的最新版本（8.0）已完全支持当前的安全配置文件草案。尽管消息签名配置文件仍需进一步完善，但大部分功能已得到支持。

原文链接: https://curity.io/blog/the-state-of-fapi-2/