Skip to main content

5. Security Considerations (安全考虑)

本节描述了使用持有者令牌时与令牌处理相关的安全威胁,并描述了如何缓解这些威胁。

5.1. Security Threats (安全威胁)

以下列表列出了针对使用某种形式令牌的协议的几种常见威胁。此威胁列表基于NIST特别出版物800-63 [NIST800-63]。

Token manufacture/modification (令牌伪造/修改)

攻击者可能生成伪造的令牌或修改现有令牌的内容(例如认证或属性声明),导致资源服务器向客户端授予不适当的访问权限。例如,攻击者可能修改令牌以延长有效期;恶意客户端可能修改断言以访问他们不应该看到的信息。

Token disclosure (令牌泄露)

令牌可能包含包括敏感信息的认证和属性声明。

Token redirect (令牌重定向)

攻击者使用为某个资源服务器生成的令牌来访问另一个资源服务器,后者错误地认为该令牌是为其生成的。

Token replay (令牌重放)

攻击者尝试使用过去已经在该资源服务器上使用过的令牌。

5.2. Threat Mitigation (威胁缓解)

可以通过使用数字签名或消息认证码 (MAC) 保护令牌内容来缓解大量威胁。或者,持有者令牌可以包含对授权信息的引用,而不是直接编码信息。此类引用必须 (MUST) 使攻击者无法猜测;使用引用可能需要服务器和令牌颁发者之间的额外交互来将引用解析为授权信息。

本文档不指定令牌的编码或内容;因此,关于保证令牌完整性保护手段的详细建议超出了本文档的范围。令牌完整性保护必须 (MUST) 足以防止令牌被修改。

针对令牌重定向

授权服务器在令牌中包含预期接收者(受众)的身份(通常是单个资源服务器或资源服务器列表)非常重要。还推荐 (RECOMMENDED) 将令牌的使用限制为特定作用域。

TLS要求

授权服务器必须 (MUST) 实现TLS。应实现哪个版本会随时间变化,并取决于实现时的广泛部署和已知安全漏洞。在撰写本文时,TLS版本1.2 [RFC5246] 是最新版本。

防止令牌泄露

必须 (MUST) 使用TLS [RFC5246] 及提供机密性和完整性保护的密码套件应用机密性保护。这要求客户端与授权服务器之间的通信交互,以及客户端与资源服务器之间的交互,都使用机密性和完整性保护。

客户端必须 (MUST) 在向受保护资源发起请求时验证TLS证书链,包括检查证书撤销列表 (CRL) [RFC5280]。

Cookie安全

Cookie通常以明文传输。因此,其中包含的任何信息都有泄露风险。因此,持有者令牌禁止 (MUST NOT) 存储在可以明文发送的cookie中。参见"HTTP状态管理机制" [RFC6265] 了解有关cookie的安全考虑。

负载均衡器部署

在某些部署中,包括使用负载均衡器的部署,与资源服务器的TLS连接在提供资源的实际服务器之前终止。这可能会在TLS连接终止的前端服务器和提供资源的后端服务器之间使令牌不受保护。在此类部署中,必须 (MUST) 采用足够的措施来确保前端和后端服务器之间令牌的机密性;对令牌进行加密是一种可能的措施。

防止令牌捕获和重放

建议如下:

  1. 令牌的生命周期必须 (MUST) 受到限制;实现此目的的一种方法是在令牌的受保护部分内放置有效时间字段。请注意,使用短期(一小时或更短)令牌可以减少泄露的影响。

  2. 必须 (MUST) 对客户端与授权服务器之间以及客户端与资源服务器之间的交换应用机密性保护。

  3. 当向资源服务器出示令牌时,客户端必须 (MUST) 验证该资源服务器的身份,按照"HTTP Over TLS" [RFC2818] 第3.1节的规定。

5.3. Summary of Recommendations (建议总结)

✅ 必须遵守的安全要求

保护持有者令牌

  • 客户端实现必须 (MUST) 确保持有者令牌不会泄露给非预期方,因为他们将能够使用它们来访问受保护资源。这是使用持有者令牌时的主要安全考虑,是所有更具体建议的基础。

验证TLS证书链

  • 客户端必须 (MUST) 在向受保护资源发起请求时验证TLS证书链。不这样做可能使DNS劫持攻击能够窃取令牌并获得非预期的访问。

始终使用TLS (https)

  • 客户端必须 (MUST) 在使用持有者令牌发起请求时始终使用TLS [RFC5246] (https) 或等效的传输安全。不这样做会使令牌暴露于可能给攻击者非预期访问权限的众多攻击。

不要在cookie中存储持有者令牌

  • 实现禁止 (MUST NOT) 将持有者令牌存储在可以明文发送的cookie中(这是cookie的默认传输模式)。确实在cookie中存储持有者令牌的实现必须 (MUST) 采取预防措施防止跨站请求伪造。

⚠️ 推荐的安全实践

颁发短期持有者令牌

  • 令牌服务器应该 (SHOULD) 颁发短期(一小时或更短)持有者令牌,特别是当向在Web浏览器或其他可能发生信息泄露的环境中运行的客户端颁发令牌时。使用短期持有者令牌可以减少它们被泄露的影响。

颁发作用域受限的持有者令牌

  • 令牌服务器应该 (SHOULD) 颁发包含受众限制的持有者令牌,最好是针对特定资源服务器。将令牌限制为特定作用域的用途和一组资源服务器,可以减少访问令牌被泄露时的损害。

不要在页面URL中传递持有者令牌

  • 持有者令牌不应该 (SHOULD NOT) 在页面URL中传递(例如,作为查询字符串参数)。相反,持有者令牌应该 (SHOULD) 在HTTP消息头或消息体中传递,这些方法不会在大多数服务器上记录令牌。

🔒 安全检查清单

使用Bearer Token时,请确保:

  • 始终使用HTTPS/TLS
  • 验证TLS证书链
  • 令牌有效期≤1小时
  • 不在URL参数中传递令牌
  • 不在可明文发送的cookie中存储令牌
  • 限制令牌的作用域和受众
  • 实施令牌完整性保护(签名/MAC)
  • 在负载均衡器场景中加密后端通信