【问题标题】:Can state parameter alone provide sufficient protection for OIDC with a confidential client?单独的状态参数能否为具有机密客户端的 OIDC 提供足够的保护?
【发布时间】:2021-09-05 10:22:41
【问题描述】:

在仔细研究 OIDC 规范和大量实施指南和文章时,我仍然无法明确确定单独的 state 参数是否可以为我的特定 OIDC 用例提供足够的保护,尽管它似乎应该是.鉴于我正在使用:

  • 授权码流程
  • 不允许重复使用代码的身份验证服务器
  • 机密客户端(使用客户端机密向身份验证服务器验证自身)
  • 存储在用户会话中的加密安全随机state

是否有任何攻击需要额外措施(nonce 或 PKCE)提供额外保护?在我看来,包括以下内容:

CSRF 攻击

攻击者使用她自己的帐户进行身份验证,获得授权代码,然后诱使用户使用她的代码访问客户端的重定向端点,将用户登录到她的帐户。防止出现这种情况:客户端将用户会话(如果有)中的state 与请求中的state 进行比较,发现不匹配,并拒绝请求。

代码重放攻击

用户登录后,攻击者可以访问他们的授权代码(例如,通过检查共享机器上的浏览器历史记录),然后使用该代码和客户端的重定向端点来触发令牌交换,记录攻击者进入用户的账户。这种情况是被阻止的:用户之前已经用代码交换了一个令牌,而认证服务器不允许它被重用。

MITM 攻击

攻击者能够读取用户代理和客户端或身份验证服务器之间的明文流量(例如恶意软件、破坏 TLS 的公司网络)。这种情况无法缓解,因为攻击者会知道在他们自己的机器上重新创建用户会话所需的所有信息。

我对以上所有的理解都正确吗?

【问题讨论】:

    标签: oauth-2.0 openid-connect openid


    【解决方案1】:

    state 参数的一个问题是它是一个客户端 验证,由每个客户端来验证此参数。但是,并非每个客户端都执行此验证,这是一个问题。

    通过添加 PKCE,我们获得了 服务器端 验证,这意味着实施不当的客户端将无法进行身份验证,身份提供者可以强制/要求使用 PKCE

    【讨论】:

    • 对于机密客户,PKCE 并不是那么重要——当您有一个机密客户时,使用被盗的授权码要困难得多。不过,如果可能的话,使用 PKCE 总比不使用好。
    猜你喜欢
    • 1970-01-01
    • 2015-01-06
    • 2020-06-18
    • 1970-01-01
    • 2017-05-02
    • 2019-09-13
    • 1970-01-01
    • 1970-01-01
    • 2012-08-17
    相关资源
    最近更新 更多