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]
答案 0 :(得分：16)
对Josh C的大答案略有不同的看法：因为它发生了客户端身份验证和授权凭证都可以表示为JWT，但它们背后的语义是不同的。
关注点分离：客户使用标识的凭据进行身份验证，即他们是所谓的subject，而他们使用向颁发的授权 / strong>即他们就是所谓的audience。或者，草案规范（https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12）的第12版说：
JWT必须包含一个“子”（主题）声明来识别 校长是JWT的主题。需要两个案例 分化：
一个。对于授权授权，通常是主题 标识访问令牌的授权访问者 被请求（即资源所有者或 授权代表），但在某些情况下，可能是一个 假名标识符或表示匿名的其他值 用户。
B中。对于客户端身份验证，主题必须是 OAuth客户端的“client_id”。
答案 1 :(得分：10)
可能很少。确定客户端的方式以及请求授权授权的方式是OAuth中的两种不同概念，因此问题分别针对这些概念：
该规范似乎暗示分离只是一个设计决策，推迟决策者找出哪些方案对他们有价值：
使用安全令牌进行客户端身份验证与使用安全令牌作为授权授权正交并可分离。它们可以组合使用或单独使用。使用JWT进行客户端身份验证只不过是客户端对令牌端点进行身份验证的另一种方法，必须与某种授权类型结合使用才能形成完整且有意义的协议请求。 JWT授权授权可以在有或没有客户端身份验证或标识的情况下使用。是否需要客户端身份验证以及JWT授权授权以及支持的客户端身份验证类型，是授权服务器自行决定的策略决策。
一个具体的可能性：分离可能允许授权服务器沿客户端类型设置不同的策略。例如，在公共客户端（如移动应用程序）的情况下，服务器不应接受客户端信用许可类型。相反，服务器可以接受公共客户端的JWT授权类型，并发出较低权限的令牌。
除此之外，我认为设计只是为客户端和服务器提供了一定的自由度 - 在迁移这部分时保持现有握手的这一部分相同 - 在需要时。