我正在研究一个用例，我正在努力实现以下目标：
使用OpenID Connect协议。规格如下：（http://openid.net/specs/openid-connect-core-1_0.html）
使用以下命令发出对/ oauth2 / access_token端点的调用：
一个。对于资源身份验证：使用grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer这是根据规范（https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12）
湾对于客户端身份验证：使用client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer这与上面#a点中列出的规范相同。
我的问题是：
我知道Open ID Connect规范只讨论“授权代码”和“隐式”授权方案。但是，我打算将Open ID规范与JWT Bearer规范结合使用。换句话说，通过JWT承载授权类型在一次调用中向OAuth2.0令牌api（/ access_token）发送身份验证和授权信息，并接收访问令牌和id_token作为回报。这是可能的还是我会违反Open ID Connect规范？
答案 0 :(得分：3)
这未在规范中定义，因为它将是循环引用：OpenID Connect的主要功能是通过传递给客户端的id_token向客户端验证用户身份。 id_token是一个描述用户和身份验证属性的JWT。客户端从用户处收到所谓的授权，以获取具有该用户信息的id_token。
如果授权是已经（必然）与用户和身份验证事件相关联的JWT，那么就不需要另一个基本上描述相同的内容（基本上是隐含授权的内容）实现）。如果授权与用户身份验证无关，则无法使用它来获取id_token，因为这会违反OpenID Connect的语义。
因此，JWT承载授权类型在OAuth 2.0（委派授权）方案中是有意义的，但在OpenID Connect（用户身份验证）方案中则没有。
当然，仍然可以使用JWT（与用户和/或用户身份验证无关）进行客户端身份验证，但之后不会将其用作授权，而是替代授权代码中的客户端密钥授予。