不记名令牌超出 OAUTH 设置 - 关于正确使用标准的问题

Question

身份验证方案的 IANA 注册表 (http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml) 声明承载身份验证方案是在 Oauth 协议的上下文中定义的。

在没有 OAuth 设置的情况下使用不记名令牌是否有意义？ 例如：我想调用另一个公司的API；我们同意将 JWT 安全令牌添加到 API 调用的自定义方案（例如，假设您不使用 OAUTH 要求的授权服务器，我们使用另一种自定义机制）。使用 Authorization http 标头和承载身份验证方案对 JWT 进行签名和编码并添加到 API 调用。

问题不在于这是否可行，因为我知道它可以并且从安全的角度来看它已经足够好（这就是为什么我没有添加关于实际实现的太多细节）。

我的问题是关于标准的使用：从正式的角度来看，如果我们在 Oauth 设置之外声明不记名令牌，我们是否正确？ 第二个问题可能是：是否可以声明自定义身份验证方案，例如“myBearer”？

谢谢你， 科拉多·塔米蒂

Answer 1

我建议您遵循 B2B 安全标准模式。通常这涉及到授权服务器，但如果没有授权服务器，出于您无法控制的原因，那么使用令牌仍然很有用，以便：

• 传达范围以表示数据区域
• 传达用于更细粒度授权规则的声明

我会围绕以下规则设计一个解决方案：

1. 拥有 API 的公司 B 必须颁发访问令牌。只有他们应该有权访问用于发布它们的私钥。然后他们可以控制特权、生存时间和其他方面。
2. 公司 A 必须调用公司 B 端点以获取访问令牌，这涉及发送凭据。收到的令牌应该是相当机密的，并且不包含敏感数据。
3. 然后，A 公司将该访问令牌发送到 B 公司的其他端点以访问数据。

即使您暂时保持 OAuth 行为较轻，这也是一种标准模式，应该很好地适合您的应用程序并支持未来的可扩展性。

使用授权标头

您提供的链接引用了 OAuth 1.0，它使用了 OAUTH 关键字 在 Authorization 标头中 - 但现在很少有人使用 OAuth v1，部分原因是它比 OAuth v2 对网络/移动设备不太友好。

OAuth v2 最佳实践涉及通过 Authorization 标头的通用 HTTP 机制发送 JWT - 请参阅 this section from the draft OAuth 2.1 spec。

如果您使用的是标准 JWT（没有更高级的功能，例如所有权证明），那么使用“不记名”对我来说是正确的选择。这仅描述了 API 消息凭据的呈现方式，并不一定意味着完整的 OAuth 解决方案已经到位。

关于授权和 B2B 的更多详情

OAuth B2B API 通常使用Client Credentials Grant，如果数据敏感度很高，第 2 步通常涉及使用 Mutual TLS。以下是 Curity 网站的一些相关链接：

• Scopes in APIs
• Claims in APIs
• Financial Grade B2B APIs