Api OAUTH设置之外的承载令牌-关于正确使用标准的问题

IANA认证方案注册中心（）声明承载认证方案是在Oauth协议的上下文中定义的

使用无OAuth设置的承载令牌有意义吗？ 例如：我想调用另一家公司的API；我们同意将JWT安全令牌添加到API调用的自定义方案（例如，假设您没有按照OAUTH的要求使用授权服务器，我们使用另一个自定义机制）。JWT经过签名和编码，并使用带有承载身份验证方案的授权http头添加到API调用中

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

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

谢谢,，

---

Corrado Tamietti

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

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

我将围绕以下规则设计解决方案：

拥有API的公司B必须发行访问令牌。只有他们才应该有权访问用于颁发它们的私钥。然后，他们可以控制特权、生存时间和其他方面

公司A必须呼叫公司B端点以获取访问令牌，这涉及到发送凭证。收到的令牌应相当保密，且不包含敏感数据

然后，公司A将该访问令牌发送到其他公司B端点以访问数据

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

授权头的使用

您提供的链接引用了OAuth 1.0，它使用了OAuth关键字 在授权标题中-但是现在很少有人使用OAuthV1，部分原因是它比OAuthV2对web/mobile更不友好

OAuth v2最佳实践涉及通过授权头的通用HTTP机制发送JWT-请参阅

如果您使用的是标准JWTs（没有更高级的功能，如持有证明），那么使用“持有者”对我来说是正确的选择。这只描述了API消息凭证是如何呈现的，并不意味着一个完整的OAuth解决方案已经就位

有关授权和B2B的更多详细信息

OAuth B2B API通常使用，如果数据敏感度很高，步骤2通常涉及使用相互TL。以下是来自安全网站的一些相关链接：

---

谢谢你，Gary，我同意这将是一个很好的模式，与我们的模式类似。我还有一个问题：在您描述的情况下，您是否会“声明”承载令牌授权方案，也就是说，即使设置不完全是OUAUTH，您是否会在http授权头中使用承载令牌和所描述的内容，或者您是否会“声明”自定义授权方案，例如，对令牌使用“myAuthorization”http头？请不要问这个问题不仅仅是“学术性”的，因为如果你使用“授权”标题，你就排除了同时使用scheme和OAUTH。我在上面的回答中添加了一个部分-我认为混淆是因为看了旧的OAUTH 1.0材料-标题中包含了“OAUTH”一词。在OAuth 2.0中不再是这种情况，这是当今的标准。谢谢Gary，您澄清了您认为在授权头中使用承载令牌是可能的，即使没有完全兼容的OAuth 2解决方案。这就是我一直在寻找的。我只是补充说，我的意图是在我的问题中提到OAUTH的2.0版本；实际上，如果您遵循承载授权方案的链接，我提供的链接将带您访问OAUTH 2.0规范。但没问题！