我对OAuth2有疑问并验证客户端是否已分配令牌。
规范说，对于机密客户端，客户端必须在请求令牌等时进行身份验证，例如使用基本身份验证头。这意味着我们可以验证客户端是否已注册，并且可以授予访问令牌。令牌请求的标头可能如下所示：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
规范还说，一旦分配了令牌，客户端就可以通过将其传递到auth头中来使用令牌来请求信息，如下所示：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
这很好，但是说我们有一个或多个客户端应用程序（让我们称之为App1和App2），以及我们分别通过Token1和Token2授予他们访问权限的服务器，我们如何确定请求包含在auth头中发送的承载令牌来自我们已分配给它的客户端应用程序。
App2（以某种方式）不能获得给予App1的令牌（恶意或其他），只是通过将其传递到auth头而不是自己的令牌来使用它来获取资源？
我们应该（甚至可能）在我们对资源发出的请求上发送两个auth标头，一个带有我们的承载令牌，另一个带有我们的客户端凭证，因此服务器可以验证令牌是否来自正确的客户端？
答案 0 :(得分：1)
简短的回答：今天不可能以标准化的方式实现。
OAuth 2.0规范今天定义了不具有您正在寻找的属性的承载令牌，因为呈现它们的客户将获得对资源的访问权限，而不会证明他们是该资产的合法所有者令牌。令牌只能通过机密（TLS）渠道交付和使用，因此它们不会以错误的客户端结束。
OAuth 2.0工作组正在开展工作，以定义所谓的“拥有证明”＃34; OAuth 2.0的扩展，允许客户端对请求进行签名，以便接收方可以验证它是否是正确的客户端。另见：http://www.thread-safe.com/2014/04/oauth-proof-of-possession-drafts.html
OAuth 2.0规范的当前迭代使用Bearer令牌尽可能简单，只是为了使编写客户端实现变得非常容易。如果您同时控制客户端和资源服务器，您可能会提出自己的自定义证明机制，但目前还没有标准的方法。