Search code examples
c#owinfiddleridentityserver3openid-connect

OWIN OpenIdConnect Middleware IDX10311 nonce cannot be validated


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

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