OWIN OpenIdConnect中间件IDX10311随机数无法验证

Question

我有一个使用OWIN中间件的应用程序用于OpenIdConnect.startup.cs文件使用app.UseOpenIdConnectAuthentication的标准实现.cookie被设置为浏览器,但它出错:

IDX10311:RequireNonce为'true'(默认值),但validationContext.Nonce为null.nonce无法验证.如果您不需要检查nonce,请将OpenIdConnectProtocolValidator.RequireNonce设置为"false".

我发现当像大多数调试项目一样运行fiddler时,会发生这种情况.返回错误,但如果我返回该站点,一切正常,我的用户已通过身份验证.有没有人在运行提琴手时看到这种行为？

随着提琴手:

• OpenIdConnect中的SecurityTokenValidated通知执行两次.
• 第二次通过IDX10311后抛出错误
• 浏览器包含有效的cookie,返回页面我可以查看有效的User.Identity数据.

没有提琴手跑:

• SecurityTokenValidated在OpenIdConnect中执行一次
• 没有抛出错误,继续加载控制器操作以进行后验证重定向Uri
• Cookie也有效且User.Identity数据正确.

想法？我可以在不运行fiddler的情况下绕过它,但是在调试时,运行fiddler来检查流量也会很不错.

Answer 1

这可能是原因吗？

你好,我想我找到了这个问题的根本原因.

我总结了我的发现:

1. 问题出在OpenIdConnect.nonce.OpenIdConnect cookie中

2. 一旦OpenID中间件启动认证会话,就会从应用程序设置此cookie(让我们称之为"ID客户端")

3. 验证完成后,cookie应立即从浏览器发送回"ID Client".我的假设是需要这个cookie从ID客户端的角度进行双重检查(即我是否真的启动了OpenID Connect授权流程？)

4. 我的很多困惑都是由"Nonce"术语引起的,在此cookie和ID服务器的OpenID Connect流程中都使用了该术语.

5. 在我的情况下,例外是由于丢失的cookie(不是ID服务器的nonce)引起的,仅仅是因为它没有被浏览器发送回"ID客户端"

因此,在我的情况下,主根是这样的:浏览器没有将OpenIdConnect.nonce.OpenIdConnect cookie发送回ID Client.在某些情况下(例如Chrome,Firefox和Edge)cookie被正确发送,而在其他情况下(IE11,Safari)则没有.

经过大量研究后,我发现问题出在浏览器上定义的Cookie限制策略中.在我的例子中,"ID客户端"嵌入在<iframe>.这导致"ID客户端"被视为"第三方客户端",因为用户没有直接在主窗口中导航到该URL.因为这是第三方,对于某些浏览器,它的cookie必须被阻止.实际上,通过设置"阻止第三方cookie",可以在Chrome上获得相同的效果.

所以,我必须得出结论:

a)如果iframe是必须的(在我的情况下,因为"ID客户端"是必须在我们的主平台应用程序的图形内容中运行的应用程序),我认为唯一的解决方案是拦截错误,并处理它一个页面,要求用户启用第三方cookie.

b)如果iframe不是必须的,那么在新窗口中打开"ID Client"就足够了.

希望这有助于某人,因为我疯了!

马尔科

Answer 2

对于 2021 年来到这里的其他人，如果出现以下情况，您可能会遇到此问题：

• 您正在重定向 http -> https
• 或者您更改了应用程序的主机域。

这两个问题都不是中间件或您的应用程序的问题，而是两个问题的组合：

• 事实上，您的应用程序仍然托管在旧的旧域或协议上。您希望通过在 Web 服务器上实施重定向来防止浏览器遇到此问题。
• Azure 中的重定向 URI（有时称为回复 URL）或您正在使用的任何 OpenIdConnect 授权服务器。您希望将其更新到新的协议或域。

我们的示例：我们有https://old.example.com/app/，现在也托管在https://new.example.com/app/。我们希望用户以前的书签仍然有效。

我们的解决方案：

1. 我们更新了重定向 URI（回复 url）以指向应用程序的新域 ( https://new.example.com/app/signin-endpoint )。理想情况下，请确保您的应用程序只列出一个 URI，并且它是 https。
2. 我们将新的域绑定添加到 IIS 中的站点（我们是老派，但对您选择的托管执行相同的操作）
3. 我们添加了到新域 (new.example.com) 的 IIS 重定向，以便用户的书签仍然有效。同样，如果您不在 IIS 上，请在您选择的 Web 服务器中实施永久重定向。

在完成上述最后一步之前，我们在 OP 的帖子中看到了错误。如果您强制使用 http -> https，则过程相同。

以下是为那些同样“老派”的人重新编写的 IIS：

<rewrite>
  <rules>
    <rule name="Redirect old.example.com to new.example.com" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="old.example.com" />
      </conditions>
      <action type="Redirect" url="https://new.example.com{REQUEST_URI}" />
    </rule>
  </rules>
</rewrite>

它位于<system.webServer>web.config 文件的部分中。享受！

Answer 3

我有同样的问题,但切换回Microsoft.Owin.Security.OpenIdConnect3.0.1版解决了这个问题

Answer 4

我知道这个问题已经有一段时间了。我的具体问题是在 Fiddler（流量检查代理）运行时与 IdentityServer 进行身份验证相关的 IDX10311 错误。我添加了一个自定义 owin 中间件，以在主机名包含“localhost”的情况下捕获并吸收 IDX13011。忽略此异常允许我们使用带有 fiddler 的网站作为解决方法。我认为这会导致身份验证过程中断，尽管我们必须在回调的浏览器地址栏中按 Enter 键才能再次进行，但这只会影响开发。

这是我们在中间件中使用的调用方法来吸收错误。但我应该指出，我们偶尔也会在生产中看到这个错误。没有解释原因，但我感觉这与 IE 浏览器的用户有关。

public override async Task Invoke(IOwinContext context) {
        try {
            await Next.Invoke(context);
        } catch (Exception ex) {
            _errorHandling = new ErrorHandling();
            if (ex.Message.Contains("IDX10803")) {
                //do something here to alert your IT staff to a possible IdSvr outage
                context.Response.Redirect("/Error/IdSvrDown?message=" + ex.Message);
            } else if(ex.Message.Contains("IDX10311") && context.Request.Host.Value.Contains("localhost")) {
                //absorb exception and allow middleware to continue
            } else {
                context.Response.Redirect("/Error/OwinMiddlewareError?exMsg=" + ex.Message + "&owinContextName=" + lastMiddlewareTypeName);
            }
        }
    }