【问题标题】:Open ID Connect with JWT Bearer Token Grant TypeOpen ID Connect with JWT Bearer Token Grant Type
【发布时间】:2015-10-26 05:21:46
【问题描述】:

我正在研究一个我试图实现以下目标的用例:

  1. 使用 OpenID Connect 协议。规格在这里:(http://openid.net/specs/openid-connect-core-1_0.html)

  2. 发出对 /oauth2/access_token 端点的调用:

    一个。对于资源认证:使用grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer 这是按照规范(https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer-12

    b.对于客户端身份验证:使用client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer 这再次与上面#a 中列出的相同规范。

我的问题是:

我知道 Open ID Connect 规范只讨论“授权码”和“隐式”授权方案。但是,我计划将 Open ID 规范与 JWT Bearer 规范结合使用。换句话说,通过 JWT Bearer Grant Type 在一次调用中将身份验证和授权信息发送到 OAuth2.0 令牌 api (/access_token),并接收访问令牌和 id_token 作为回报。这是可能的还是我会违反 Open ID Connect 规范?

【问题讨论】:

    标签: authentication oauth-2.0 openid-connect aaa-security-protocol


    【解决方案1】:

    规范中没有说明不能支持 oidc 范围。因此,无论哪种方式都可以推断出来。我假设如果执行身份验证以获取初始 JWT,那么返回 id_token 就可以了。然而,我正在继续研究这个。在此之前,如果客户端在令牌调用中发送 oidc 范围,则采取同样发送 id_token 的方法。

    【讨论】:

      【解决方案2】:

      这在规范中没有定义,因为它是一个循环引用:OpenID Connect 的主要功能是通过传递给客户端的id_token 向客户端验证用户。 id_token 是一个描述用户和身份验证属性的 JWT。客户端从用户那里收到所谓的授权,以获取带有该用户信息的id_token

      如果授权已经是(必然)与用户和身份验证事件相关联的 JWT,则无需获取另一个基本描述相同的 JWT(基本上这就是隐式授权所实现的)。如果授权与用户身份验证无关,则不能使用它来获取id_token,因为这会违反 OpenID Connect 的语义。

      因此,JWT Bearer 授权类型在 OAuth 2.0(委托授权)场景中有意义,但在 OpenID Connect(用户身份验证)场景中无效。

      当然,仍然可以将 JWT(与用户和/或用户身份验证无关)用于客户端身份验证目的,但它不会用作授权,而是用作授权代码中客户端机密的替代方案授予。

      【讨论】:

      • 谢谢!在我的场景中,资源所有者(用户)和客户端之间实际上没有区别。因此,根据我的理解,如果资源所有者/客户端使用“JWT-BEARER”授权从授权服务器请求访问令牌,则无需获取任何具有相同信息的“id_token”。如果之后将访问令牌传递给另一方,那么该方获取用户信息的唯一方法是调用 /userinfo 端点,如 Open ID Connect 规范中所述。我的理解正确吗?
      • 这将混淆 OAuth 2.0 和 OpenID Connect:访问令牌可用于获取用户信息,但这并不一定意味着用户存在(不再存在)并且它确实公开了有关身份验证事件本身(例如时间戳、方法)和其他元数据(例如受众)。另见oauth.net/articles/authentication
      猜你喜欢
      • 2019-10-15
      • 2021-08-02
      • 2019-03-24
      • 2020-08-15
      • 2021-04-28
      • 1970-01-01
      • 2021-05-10
      • 2017-03-15
      • 1970-01-01
      相关资源
      最近更新 更多