【问题标题】:OpenID Connect - Implicit Flow NonceOpenID Connect - 隐式流随机数
【发布时间】:2019-12-26 01:34:36
【问题描述】:

对于如何将 nonce 参数实际用于 OpenID Connect,我感到非常困惑。我正在尝试通过 Microsoft Azure 和 Google 对用户进行身份验证,分别使用 Azure 和 Google 登录。

这是我当前的(隐式)流程。

  1. 当用户在浏览器中加载我们的登录页面时,google 和 azure msal 这两个客户端库将使用我们的客户端 ID 进行初始化。
  2. 登录页面上有两个按钮,每个按钮都会打开来自相应提供商的弹出窗口,重定向到 Google/Microsoft 登录页面。
  3. 用户输入他们的 Google/Microsoft 用户名和密码并登录。成功验证后弹出窗口关闭,并且 ID 令牌返回到浏览器 JavaScript。
  4. 浏览器 JavaScript 获取 ID 令牌并将其发送到我们的后端,然后我们在后端验证 JWT。
  5. 验证成功后,我们会为用户创建一个会话,并将浏览器重定向到仪表板。

我很困惑 nonce 在哪里适合所有这些,因为我使用的是基于 JavaScript 的流而不是 HTTP,所以不需要?是否由浏览器客户端库隐式处理?

如何确保攻击者无法在 Google/Microsoft 服务器和浏览器以及浏览器和后端之间嗅探 ID 令牌,而只是重新发送该 ID 令牌以验证用户身份?

【问题讨论】:

    标签: node.js azure oauth openid google-identity


    【解决方案1】:

    noncestate 非常相似,也用于对抗replay 攻击。主要区别在于nonceid_token 中返回,而state 在重定向URI 中返回。通常库应该为您生成它并在 id_token 中进行验证。

    顺便说一句,如果您可以访问后端,我建议您改用代码流(或至少使用新的 PKCE 流),因为隐式流很快就会被弃用。

    【讨论】:

    • 我没有看到或配置关于任一提供者的随机数或状态参数。它们只是隐含在前端库中吗?我也在使用隐式流程,因为该应用程序是单页应用程序,所有操作基本上都是 REST API 调用。本质上,我将 google/microsoft ID 令牌交换为后端生成的令牌。然后我们将这个新令牌用于所有 REST 调用。
    • 通常库会负责生成随机数,但有些可能不会...您是否尝试过使用代码流但通过 REST 调用将代码发送到后端,然后您的后端可以交换获取访问令牌,然后通过服务器到服务器调用获取用户信息? id_token加密的,所以如果有人可以拿到它,他们可以看到里面的用户信息。
    • 如果不用于后端身份验证,隐式流的目的到底是什么 - Google 有关于使用隐式流进行后端身份验证的文档,这就是我想知道的原因。我确实有使用隐式流程的某些原因,一个是为了避免重定向。 developers.google.com/identity/sign-in/web/backend-auth
    • 如果授权页面以弹窗方式打开,可以避免重定向,请看docs.simplelogin.io/docs/frontend-js(免责声明:我是SimpleLogin创始人)。刚看了你发的google链接,很奇怪Google推荐这个“反模式”! Id_token,与它的名字相反,它不是一个“秘密”,它是一个 encoded json 的简化。
    • 是的,我看到了您的简单登录库,我的代码现在做同样的事情,它直接在前端本身获取用户信息 JWT - 不连接到后端。然后我们将 JWT 传递到后端以将其交换为 API 密钥,因为我们的数据库中存在用户的电子邮件。我以为你说这是糟糕的策略?
    猜你喜欢
    • 2016-11-19
    • 2018-06-26
    • 2018-06-19
    • 2017-06-28
    • 1970-01-01
    • 2015-08-16
    • 2015-02-25
    • 2017-04-18
    • 2017-12-02
    相关资源
    最近更新 更多