OAuth2 JWT配置文件引入了将JWT用作授权授权和客户端身份验证的可能性 .
JWT客户端身份验证功能独立于某种授权类型，可以与任何授权类型一起使用，也可以与客户端凭据授予一起使用 .
但是，使用JWT授权类型似乎与使用JWT客户端身份验证的客户端凭据授权完全相同，只是语法略有不同 .
在这两种情况下，客户端都会联系令牌 endpoints 以获取访问令牌：
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]
2 回答
Josh C对这个伟大答案的看法略有不同：因为它发生的客户端身份验证和授权凭证都可以表示为JWT，但它们背后的语义是不同的 .
它是关于关注点的分离：客户端使用凭证进行身份验证 identifies them 即他们是所谓的
subject，而他们使用已发布的授权 to them ，即它们就是所谓的audience. 或者作为草案规范的第12版（https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12）说：可能很少 . 确定客户端的方式以及请求授权授权的方式是OAuth中的两种不同概念，因此问题分别针对这些概念：
客户端是否可以使用JWT对授权服务器进行身份验证？是 .
客户端是否可以使用JWT发出授权请求？是 .
该规范似乎暗示分离只是一个设计决策，推迟决策者找出哪些方案对他们有 Value ：
一个具体的可能性：分离可以允许授权服务器沿客户端类型设置不同的策略 . 例如，在公共客户端（如移动应用程序）的情况下，服务器不应接受客户端信用许可类型 . 相反，服务器可以接受公共客户端的JWT授权类型，并发出较低权限的令牌 .
除此之外，我认为设计只是为客户端和服务器提供了一定的自由度 - 在需要时，在迁移这部分时保持现有握手的这一部分相同 .