【问题标题】:In OpenID Connect, what's the purpose of "code id_token" hybrid workflow when "code" flow does the same thing more securely?在 OpenID Connect 中,当“代码”流更安全地做同样的事情时,“代码 id_token”混合工作流的目的是什么?
【发布时间】:2021-03-30 04:17:36
【问题描述】:

在使用 OpenID Connect/OAuth2 参加 ASP.NET 身份安全课程时,我了解了不同工作流程的差异和优缺点。

具体来说,我对 code id_token 混合工作流程的用途感到困惑,它就像授权代码工作流程一样,只是它还从前端通道返回一个(简化的)id_token

所以我的第一个问题是,如果稍后要通过后台通道再次检索完整的 id 令牌和访问令牌,那么淡化 id_token 的目的是什么首先由第一个(不太安全的)请求返回?

另一件事是关于安全性:课程讲师提到,即使没有 PKCE 保护,使用 code id_token 的混合工作流程也被认为是安全的,原因有两个:

  1. 初始的id_token 包含一个c_hash 值,将其与授权码相关联,保护其免受授权码泄漏/重放攻击

我的问题:由于初始id_token 以完全相同的方式与授权码一起返回,如果授权码被泄露,我们是否应该假设id_token 也被泄露,使这种保护无效?

  1. nonce 字符串确保一次性使用授权码

我的问题: 由于nonce 以纯文本形式包含在 URL 中,如果攻击者设法在合法用户之前向客户端发布重定向响应以及授权代码,则攻击会成功吧?

鉴于这些,是否正确地说具有 PKCE 保护(加上 nonce)的授权代码工作流比没有 PKCE 的 code id_token 混合工作流更安全?

谢谢。

【问题讨论】:

    标签: oauth-2.0 asp.net-identity identityserver4 openid-connect


    【解决方案1】:

    Hybrid Flow 的用例适用于前端和后端需要不同令牌的 Web 客户端:

    • Web 前端接收 id 令牌并可以读取其声明
    • 只有 Web 后端接收访问 + 刷新令牌,然后向 Web 前端发出 auth cookie

    混合流动特性

    使用 code id_token 响应类型进行重定向,并在查询字符串中接收 id 令牌以及授权代码。为防止替换攻击,您在重定向期间提供 nonce 值,然后验证响应中是否存在与 id 令牌声明相同的值。

    安全

    就安全性而言,我想说它并不比 PKCE 差,因为它的安全性经过适当考虑并包含在 Open Id Connect Specification 中。

    混合使用

    如果您想要上述行为,您只会使用混合流。它不是最常用的流,因为在使用身份验证 cookie 的 Web 应用程序中,前端无论如何都可以很容易地通过其后端获取用户信息,而后端又可以调用用户信息端点。

    【讨论】:

      猜你喜欢
      • 2019-12-09
      • 2018-05-20
      • 1970-01-01
      • 2017-06-28
      • 2022-01-14
      • 2016-02-13
      • 2015-12-11
      • 2018-06-19
      • 2018-06-04
      相关资源
      最近更新 更多