OAuth2 JWT配置文件引入了将JWT用作授权授权和客户端身份验证的可能性。
JWT客户端身份验证功能独立于某种授权类型，可以与任何授权类型一起使用，也可以与客户端凭据授予一起使用。
但是，使用JWT授权类型似乎与使用JWT客户端身份验证的客户端凭据授权完全相同，只是语法略有不同。
在这两种情况下，客户端都会联系令牌端点以获取访问令牌：
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=[JWT]
VS
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=[JWT]
Josh C对这个伟大答案的看法略有不同：因为它发生的客户端身份验证和授权凭证都可以表示为JWT，但它们背后的语义是不同的。
它涉及关注点的分离：客户使用识别它们的凭证进行身份验证，即它们是所谓的subject，而它们使用发给它们的补助金，即它们就是所谓的audience。或者作为草案规范的第12版（https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12）说：
- JWT必须包含一个“子”（主题）声明，用于识别作为JWT主体的主体。需要区分两种情况： A.对于授权授权，主体通常标识正在为其请求访问令牌的授权访问者（即，资源所有者或授权代理），但在某些情况下，可以是假名标识符或表示匿名的其他值。用户。 B.对于客户端身份验证，主题必须是OAuth客户端的“client_id”。
可能很少。确定客户端的方式以及请求授权授权的方式是OAuth中的两种不同概念，因此问题分别针对这些概念：
该规范似乎暗示分离只是一个设计决策，推迟决策者找出哪些方案对他们有价值：
使用安全令牌进行客户端身份验证与使用安全令牌作为授权授权正交并可分离。它们可以组合使用或单独使用。使用JWT进行客户端身份验证只不过是客户端对令牌端点进行身份验证的另一种方法，必须与某种授权类型结合使用才能形成完整且有意义的协议请求。 JWT授权授权可以在有或没有客户端身份验证或标识的情况下使用。是否需要客户端身份验证以及JWT授权授权以及支持的客户端身份验证类型，由授权服务器自行决定是否作出策略决策。
一个具体的可能性：分离可以允许授权服务器沿客户端类型设置不同的策略。例如，在公共客户端（如移动应用程序）的情况下，服务器不应接受客户端信用许可类型。相反，服务器可以接受公共客户端的JWT授权类型，并发出较低权限的令牌。
除此之外，我认为设计只是为客户端和服务器提供了一定的自由度 - 在需要时，在迁移这部分时保持现有握手的这一部分相同。