什么是持有者令牌？使用、风险和最佳实践

Scrapeless Scraping API 在 x-api-token 头中使用帐户 API 密钥，而不是 OAuth 持有者认证，这表明凭据类型和 HTTP 呈现方案是不同的设计选择。

什么是持有者令牌？

持有者令牌是一种安全令牌，其权威基于持有。单词“持有者”意味着携带令牌的一方可以将其出示给受保护的资源。与持有证明设计不同，基本持有者流程不要求调用方为每个请求展示对单独加密密钥的控制。

RFC 6750 定义了 OAuth 2.0 持有者令牌的使用。它描述了客户端如何将访问令牌发送到资源服务器，服务器如何返回身份验证挑战和错误，以及实现必须解决的安全威胁。

持有者令牌在 HTTP API 中很常见，因为客户端交互简单。授权服务器发放访问令牌，客户端存储它，并将其与 API 请求一起发送。简单性将责任转移到传输安全、令牌处理、验证、范围设计和事件响应上。

Authorization 头是如何工作的

首选的 HTTP 呈现使用 Authorization 请求头与 Bearer 方案：

Authorization: Bearer REDACTED

方案名称在 HTTP 身份验证解析中不区分大小写，但客户端应使用常规大写。令牌值对于客户端是不透明的，除非令牌配置文件明确给予客户端检查它的理由。客户端不应通过解码访问令牌内容来做出授权决策；资源服务器是执法点。

请求必须使用 HTTPS，客户端必须根据其平台信任模型验证服务器的证书。头仍可能通过应用日志、跟踪代理、调试代理、崩溃报告或浏览器扩展泄露，因此每个观察请求的层都需要编辑规则。

持有者令牌、访问令牌和 OAuth

访问令牌是表示访问资源授权的凭证。持有者描述了该令牌的使用方式。OAuth 是客户端可以在授权下获得访问令牌的框架。这些术语相关但不可互换。

OAuth 访问令牌通常是持有者令牌，但另一个配置文件可以将令牌绑定到客户端持有的密钥。非 OAuth 系统也可以发明持有者风格的令牌，尽管使用标准方案而不遵循相关的安全和错误语义会造成混淆。

授权代码不是资源 API 的持有者访问令牌。它是一个短期的中间凭证，在授权服务器的令牌端点上进行交换。刷新令牌也不会发送到普通资源服务器；它与授权服务器配合使用，以继续现有的授权。

持有者令牌与 API 密钥和 JWT 的比较

JWT可以是一个承载令牌，但并不是每个JWT都是访问令牌，且并不是每个承载令牌都是JWT。一个签名的JWT证明了一个被批准的发行者保护了声明不被篡改；它并不能证明呈现者是预期的持有者，除非资料中增加了发件人绑定。

不透明和自包含的承载令牌

不透明令牌

不透明令牌是一个不可预测的值，其含义由授权基础设施持有。资源服务器可以调用一个检查端点，使用共享令牌存储，或依赖于解决令牌的网关。中央查找可以快速反映撤销和策略变更，但它增加了可用性、延迟和缓存决策。

自包含令牌

自包含令牌携带资源服务器可以在本地验证的声明。JWT是一种常见的表示形式。服务器在严格的配置下验证签名或消息认证码，然后检查发行者、受众、时间、令牌类型、范围以及任何所需的确认声明。

RFC 8725提供了JWT安全最佳当前实践。它警告算法混淆、弱验证、跨JWT混淆以及盲目信任接收的声明。资源服务器必须配置允许的算法和预期的令牌配置，而不是接受令牌头请求的任何内容。

资源服务器必须验证的内容

• 令牌的完整性或活动状态。 在允许的算法下验证签名，或通过受信任的授权系统解析不透明令牌。
• 发行者。 仅接受为此资源配置的授权服务器发出的令牌。
• 受众。 确认该令牌是为此API或资源集发行的。
• 生命周期。 强制执行过期和任何提前条件，并留有少量文档时钟偏差。
• 令牌配置和类型。 防止ID令牌、授权码或来自其他协议上下文的令牌被接受为API访问令牌。
• 范围或授权声明。 确认令牌允许请求的操作。
• 资源级策略。 即使令牌范围广泛，也要检查租户、所有权、角色、对象状态和其他领域规则。

有效的签名只是一个检查。它证明了令牌是由受信任的密钥在接受的算法下保护的。它并不能证明令牌指向此API，当前，具有所需权限或可以访问此特定记录。

承载令牌安全风险

主要风险是令牌泄露。复制的承载令牌可以在到期、被撤销或被另一政策控制拒绝之前使用。通过URL、应用程序日志、支持截图、浏览器存储、引荐头、代理跟踪、源代码控制或被攻击的客户端设备可能会发生暴露。

URL特别危险。查询字符串出现在Web服务器访问日志、浏览器历史、分析系统和复制的链接中。RFC 6750在狭窄条件下定义了一种表单编码的主体方法，并记录了URI查询的使用以实现兼容性，但新客户端应使用授权头。

跨站脚本可能会暴露浏览器可访问的令牌。将长时间存活的承载令牌保存在本地存储中使其可供同一来源中执行的恶意脚本使用。浏览器架构应最小化令牌对JavaScript的暴露，使用短访问生命周期，强制执行强内容安全政策，并在适当时考虑后端前端模式。

按客户端类型的令牌存储

后端服务将令牌存储在服务器端内存或已批准的受保护凭证存储中，并限制对需要它们的工作负载身份的访问。除非有经过审核的理由和保护模型，否则令牌不应写入磁盘缓存、环境转储或一般日志。

已安装的应用程序使用可用的操作系统安全存储。浏览器客户端的环境更加暴露，应该尽可能缩短令牌生命周期和脚本访问。会话cookie并不自动更安全；cookie设计需要安全、HttpOnly、SameSite、跨站请求伪造控制和服务器端会话策略。

没有存储选择可以修复一个强大的令牌。保持范围狭窄、受众特定、生命周期短，并通过服务器端授权保护资源。

发件人约束的替代方案

发件人约束的令牌要求呈现者证明拥有单独的密钥，从而降低被盗令牌字符串的价值。展示拥有权证明，或DPoP，将OAuth令牌与应用程序密钥绑定，通过签名证明附加到请求中。

RFC 9449定义了OAuth DPoP。互斥TLS是另一个适用于合适的机密客户端环境的发件人约束方法。这些设计增加了密钥生成、存储、重放检测和互操作性要求，因此应在明确的威胁模型下进行选择。

过期、撤销和检查

短期访问令牌限制了泄露令牌的有效时间。客户端可以通过授权会话或刷新令牌过程获得新访问权限。刷新凭证应得到更强的保护，因为它可以延长访问超出一个访问令牌的生命周期。

不透明令牌可以通过检查或中央查找反映撤销。自包含令牌通常在到期之前被接受，除非资源服务器检查撤销或会话状态。正确的设计在立即的策略变化、延迟、可用性、缓存和风险之间取得平衡。

注销语义必须定义。结束本地客户端会话、撤销刷新令牌、撤销访问令牌和结束授权服务器会话是不同的操作。用户界面应描述它实际使什么失效。

常见的承载令牌用例

Bearer 令牌检查清单

1. 仅通过 HTTPS 发送令牌。 验证目标服务器，并将令牌排除在 URL 之外。
2. 使用授权头。 遵循 API 的文档方案，不要发明替代的放置方式。
3. 发布狭义权限。 限制受众、范围、生命周期、租户和资源权限。
4. 验证完整的令牌配置。 单独的签名是不够的。
5. 在可观察性导出之前进行编辑。 覆盖头部、跟踪、异常、请求转储和支持工具。
6. 保护客户端类型的存储。 公共客户和机密客户具有不同的能力。
7. 计划撤销和事件响应。 了解哪些令牌、授权和会话可以被禁用，以及资源服务器观察更改的速度。

结论

Bearer 令牌很强大，因为它使授权的 API 调用变得简单：呈现令牌，资源服务器评估其权限。这个特性也使得披露变得严重。安全的 Bearer 令牌系统使用 TLS、授权头、严格的令牌配置验证、狭窄的受众和范围、短的生命周期、保护的存储、积极的编辑和撤销控制。当盗窃风险需要更强的保证时，发送者约束令牌增加了与客户持有的密钥相关的证明。