身份验证方案的IANA注册表(http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml)声明承载认证方案是在Oauth协议的上下文中定义的。
在没有OAuth设置的情况下使用承载令牌有意义吗？例如：我想调用另一家公司的API；我们同意将JWT安全令牌添加到API调用的自定义方案(例如，假设您没有按照OAUTH的要求使用授权服务器，我们使用另一种自定义机制(。JWT使用带有承载身份验证方案的Authorization http头进行签名和编码，并添加到API调用中。
问题不在于这是否可行，因为我知道它可以，而且从安全角度来看，它已经足够好了(这就是为什么我没有添加太多关于实际实现的细节(。
我的问题是关于标准的使用：从形式的角度来看，如果我们在Oauth设置之外声明无记名代币，我们是对的吗？第二个问题可能是：是否可以声明自定义身份验证方案，例如"myBearer"？
谢谢，Corrado Tamietti
我建议您遵循B2B安全的标准模式。通常这涉及授权服务器，但如果没有授权服务器，由于您无法控制的原因，那么使用令牌仍然有用，以便：
- 通信范围以表示数据区域
- 传达用于细粒度授权规则的声明
我会围绕以下规则设计一个解决方案：
- 拥有API的B公司必须颁发访问令牌。只有他们才能访问用于发布它们的私钥。然后，他们可以控制特权、生存时间和其他方面
- 公司A必须调用公司B端点才能获得访问令牌，这涉及到发送凭证。收到的令牌应该是相当机密的，并且不包含敏感数据
- 公司A然后将该访问令牌发送到公司B的其他端点以访问数据
即使您暂时保持OAuth行为较轻，这也是一种标准模式，应该非常适合您的应用程序并支持未来的可扩展性。
授权标题的使用
您提供的链接引用了OAuth 1.0，它使用了OAuth关键字在Authorization头中-但现在很少有人使用OAuth v1，部分原因是它比OAuth v2对web/移动更不友好。
OAuth v2的最佳实践包括通过授权标头的通用HTTP机制发送JWT——请参阅OAuth 2.1规范草案中的这一部分。
如果您使用的是标准JWT(没有更高级的功能，如拥有证明(，那么对我来说，使用"承载"是正确的选择。这只描述了API消息凭据的呈现方式，而不一定意味着已经有了完整的OAuth解决方案。
授权和B2B的更多详细信息
OAuth B2B API通常使用客户端凭据授予，如果数据敏感度很高，步骤2通常涉及使用双向TLS。以下是Curity网站的一些相关链接：
- API中的作用域
- API中的声明
- 金融级B2B API