OWIN OpenIdConnect Middleware IDX10311 nonce cannot be validated

Question

I have an application using the OWIN middleware for OpenIdConnect. The startup.cs file uses the standard implementation of app.UseOpenIdConnectAuthentication. The cookie is set to the browser, but it errors with:

IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.

I've found that when running fiddler as I do for most debug projects this behavior happens. The error is returned, but if I go back to the site everything is working and my user is authenticated. Has anyone seen this behavior when running fiddler?

With fiddler:

• SecurityTokenValidated notification in OpenIdConnect is executed twice.
• After the second pass through the IDX10311 error is thrown
• Browser contains the valid cookie, going back to the page I can view the valid User.Identity data.

Running without fiddler:

• SecurityTokenValidated executes once in OpenIdConnect
• No error thrown, proceeds to load up controller action for post authentication redirect Uri
• Cookie also valid and User.Identity data correct.

Ideas? I can get around it without running fiddler, but when debugging it would be nice to also run fiddler to inspect traffic.

Solution 1

I know it's been a while on this one. My specific issue was with the IDX10311 error in relation to authenticating with IdentityServer while Fiddler (traffic inspector proxy) was running. I added a custom owin middleware to catch and absorb the IDX13011 in the case where the hostname contained "localhost". Ignoring this exception allowed us to use the site with fiddler as a workaround. I think it causes breaks in the authentication process though where we have to press enter in the browser address bar on the callbacks to get it going again, but this only affects development.

Here's the invoke method we used in the middleware to absorb the error. I should note though that we have seen this error in production occasionally as well. No explanation for a cause, but I have a feeling it is related to users on IE browsers.

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);
            }
        }
    }

Solution 2

Maybe is this the cause?

Hello there, I think I found the root cause of this issue.

I'm summing up my discoveries:

1. The problem is in the OpenIdConnect.nonce.OpenIdConnect cookie

2. This cookie is set from the app (let's call this "ID Client") as soon as the OpenID Middleware init an authentication session

3. The cookie should be sent back from the browser to the "ID Client" as soon as the authentication has been completed. My assumption is that this cookie is needed to have a double check from the ID client point of view (i.e. did I really started an OpenID Connect authorization flow?)

4. A lot of confusion in me was caused by the "Nonce" term, used both in this cookie and in the OpenID Connect flow from the ID server.

5. The exception, in my case, was caused by the missing cookie (not the nonce of the ID Server), simply because it wasn't sent by the browser back to the "ID client"

So the main root, in my case, was this: OpenIdConnect.nonce.OpenIdConnect cookie was not sent back to the ID Client by the browser. In some cases (i.e. Chrome, Firefox and Edge) cookie was sent correctly, while in others (IE11, Safari) it wasn't.

After a lot of research, I discovered that the problem was on the Cookie restriction policy, defined on the browser. In my case, the "ID client" is embedded in an <iframe>. This cause the "ID Client" to be seen as a "third-party client", because the user didn't navigate to that URL directly in the main window. Because this is a third-party, for some browsers, it's cookies have to be blocked. Indeed the same effect may be obtained on Chrome, by setting "Block third-party cookies".

So, I have to conclude that:

a) If iframe is a must (as in my case, because "ID Clients" are apps that must run inside the graphic content of the our main platform app), I think the only solution is to intercept the error, and handle it with a page, asking the user to enable third party cookies.

b) If iframe is not a must, it should suffice opening the "ID Client" in a new window.

Hope this helps somebody, because I got crazy!

Marco

Solution 3

I had the same problem but switching back the Microsoft.Owin.Security.OpenIdConnect to version 3.0.1 solved the issue

Solution 4

For anyone else who gets here in 2021, you'll likely get this issue if:

• You're redirecting http -> https
• Or you've changed your app's host domain.

Both of these aren't an issue with the middleware or your app, but it's about the combination of two issues:

• The fact that your app is still hosted on the old old domain or protocol. You want to prevent browsers hitting that by implementing a redirect on the web server.
• The redirect URI (sometimes know as reply URL) in Azure or whichever OpenIdConnect authorization server you're authenticating with. You want to get this updated to the new protocol or domain.

Our example: We had https://old.example.com/app/ that was now also hosted at https://new.example.com/app/. We wanted users' previous bookmarks to still work.

Our solution:

1. We updated the redirect URI (reply url) to point to the new domain for the app (https://new.example.com/app/signin-endpoint). Ideally, make sure there is only one URI listed for your app and that it's https.
2. We added the new domain binding to the site in IIS (we're old school, but do the same for your hosting of choice 😊)
3. We added an IIS redirect to the new domain (new.example.com) so that users' bookmarks still work. Again if you're not on IIS, implement a permanent redirect in the web server of your choice.

Until we had the final step above, we were seeing the error in the OP's post. It's the same process if you're forcing http -> https.

Here is the IIS re-write for those who are also "old school":

<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>

It goes in the <system.webServer> section of your web.config file. Enjoy!

Solution 5

For me changing reply url in Azure active directory works.

This happens when you enable SSL because it changes only the sign on URL to the HTTPS URL while the reply URL remains the same HTTP URL.

When you try to access your app using the https URL, it sets a cookie with a unique number(nonce) in your browser and hits Azure AD for authentication. After authentication, the browser has to give access to that cookie. But since the sign on URL and reply URL are different the browser does not recognize your app and does not give access to that cookie and hence the application throws this error.

View more solutions

Comments

[gilm0079]

strike my comment. I was thinking about a different ID server issue. Although, your answer seems to be about something else than what I'm seeing. My problem just happens when I was running fiddler for traffic inspection while debugging the project. it works fine otherwise.

[Vladislav]

for me it appeared to be a browser issues. IE11 did reproduce this problem, while FF - no. Thanks for the suggestions

[Box Very]

for local/test environment version >3.0.1 not works, I think related with fake SSL certificate. However for real SSL certificate, version> 3.0.1 seems works fine.

[neleus]

We had the same issue. The problem itself is not related to Azure but to OpenIdConnect middeware how it handles http and https redirect urls.

[Heinzlmaen]

But how do I fix this, without disabling SSL?

[Ashutosh B Bodake]

@Heinzlmaen You don't need to disable the SSL. You need to change reply URL in Azure AAD accordingly.

[jrummell]

Can you elaborate on what that means?

[Glenn Ferrie]

+1 "You're redirecting http -> https" --- this did the trick. my Azure AD app registration had the wrong protocol in the reply URL, http not https