2025企业API安全指南：防护令牌与凭证盗用的新策略

当前，大多数企业在构建数字化解决方案时都采用基于调用API时，这些客户端需要获取API消息凭证。通常，用户需要先完成身份验证，才能获得这些凭证并使用应用程序。

2024年，针对API的网络攻击已成为企业面临的重大安全隐患。攻击者一旦获取API消息凭证，就可能访问受保护的数据。因此，企业必须采用最新的API防护措施，遵循最佳实践，并尽可能实施强安全策略，以防止数据泄露。

采用OAuth 2.0授权框架

实施OAuth 2.0需要集成授权服务器，用于颁发访问令牌。这一组件由安全专家设计，可实现高级安全功能。然而，不同的API、客户端和用户场景需要选择最优的OAuth 2.0特性，这需要专业的洞察力。以下是Curity公司推荐的最佳实践方案。

B2B API客户端需提供持有证明

在为商业伙伴提供API时，采用基于标准的“持有证明访问令牌”是一种简单而有效的方法。该方法通过底层安全通信通道，将访问令牌与TLS客户端证书绑定。商业伙伴的应用程序在后续的所有API请求中，都需要同时提交访问令牌和对应的TLS客户端证书。

实际案例

商业伙伴可以选择自行生成客户端证书，或者向API提供方申请证书。随后，这些证书会被配置到企业的授权服务器中。为简化集成流程，可以通过正向或反向代理终止双向TLS连接，从而避免对客户端或API代码的影响。

浏览器API客户端使用最强Cookie

对于基于浏览器的应用，浏览器本身就是终端客户端。由于为每个终端用户颁发客户端证书并不实际，因此证书绑定访问令牌的方案可能无法适用。然而，企业仍需采取措施防范令牌和数据的窃取。

浏览器应用主要面临跨站脚本（XSS）攻击的威胁，恶意代码可能窃取浏览器中的令牌和数据。为了降低风险，建议避免在浏览器中存储令牌。最佳方案是采用前端后端（BFF）模式，由BFF向浏览器颁发具备HTTP-only, SameSite=strict属性的安全Cookie，而不是直接使用令牌。虽然无法完全消除XSS威胁，但这种方法可以显著降低其影响，并防止令牌泄露。

令牌处理模式

BFF还可以选择使用客户端证书接收证书绑定访问令牌。尽管浏览器请求本身无法提供持有证明，但通过BFF可以实现更全面的防护。

移动API客户端采用认证机制

传统的OAuth安全移动应用通常遵循《OAuth 2.0 for Native Apps》标准，通过系统浏览器完成用户认证，然后将授权码转发给应用以换取令牌。然而，与浏览器应用类似，为终端用户设备安装客户端证书以实现证书绑定令牌的方案通常不可行。

移动应用属于公共客户端，可能会遭到恶意应用的仿冒攻击，从而窃取令牌。为缓解这一风险，建议使用HTTPS重定向URI和代码交换证明密钥（PKCE）。尽管如此，刷新令牌仍然可能被窃取，进而导致攻击者获取新的访问令牌。

强化移动流程

自2017年RFC 8252发布以来，移动设备的能力显著提升。如今，所有移动设备都配备了硬件级密钥，可以在认证前通过数字签名验证客户端的真实性。利用设备密钥，可以进一步强化移动认证流程，防止仿冒并保护刷新令牌。

实施零信任后端

在零信任架构下，API需要对所有请求进行业务授权，并通过访问令牌中的安全值来实现这一目标。无论调用方来自内网还是外网，API都应执行严格的验证。

关键技术

《实施零信任API》一文详细介绍了验证访问令牌、基于声明的授权以及在多API间安全共享身份值的关键技术。此外，云原生平台提供了额外的基础设施安全层。例如，SPIFFE方案允许每个后端组件获取工作负载身份及配套密钥对，从而要求后端API和数据库通过双向TLS连接验证工作负载身份。这种机制确保了内部请求的机密性，并限制了合法调用方的范围。

添加密码学支持的用户认证

即使API和客户端实施了强安全措施，账户劫持仍然是一个重大威胁。传统的密码登录方式存在多种隐患，例如服务器漏洞可能导致大量密码泄露、密码易受钓鱼攻击，以及在移动端的用户体验较差。

通行密钥认证

2024年推荐增加“通行密钥认证”作为登录选项。该方案基于密码学密钥对，提供强认证，同时简化用户体验。用户可以为账户注册多个通行密钥，并通过邮箱验证的账户恢复机制，在设备丢失的情况下恢复访问。

强认证需要与可靠的API访问控制相结合。OAuth客户端不应直接实现认证，而应由授权服务器协调认证流程。用户登录后，授权服务器会向客户端颁发最小权限的访问令牌，从而限制其对API的访问范围。

结论

设计最佳的安全防护方案需要深入理解API、客户端及其运行环境。某些连接类型可以采用持有证明机制，而其他场景则需要根据实际需求选择不同的最佳实践。

通过投资构建现代化令牌架构的组件，企业可以有效管理安全风险。一旦掌握了基础模块，相同的安全模式可以复用于多种场景，包括保护软件供应链等关键组件。

正确实施这些方案可以帮助企业构建面向未来的平台：复杂的安全代码被外部化，业务组件只需简单代码即可实现安全；通过升级授权服务器，企业可以持续获得最新的安全能力支持。这种设计不仅能够扩展到大量API及其客户端，还能助力企业的数字化方案实现安全增长。

原文链接: https://curity.io/blog/protect-against-token-and-credential-theft-in-2024/