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.

Answerable

Possibly this? github.com/IdentityServer/IdentityServer3/issues/542 – Naashom

Thanks Brock. I've looked at that thread in the past. Looks like for many it is an unresolved issue. I'll check out your suggestions from the thread though. I'm hoping it is not a MS Katana bug though as Dominick suggested as MS hasn't updated that nuget package in a while. – Answerable

@Answerable did you find a solution? – Corneille

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

Answerable

Answer 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

Ingraft

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. – Answerable

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

Answer 3

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

Counseloratlaw

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. – Mccarty

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

Hylton

+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 – Overlord

Answer 5

I know its an old post but I had this problem and nothing was working for me, after lose my mind behind a solution to make my enterprise application works I end up fixing it by setting the multi-tenanted option to yes in azure (in Azure select: app registration>settings>properties, set multi-tenanted to yes and click save).

hope it helps someone, couldn't see nobody mentioning it.

Omari

Answer 6

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.

Garlinda

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. – Dihedral

But how do I fix this, without disabling SSL? – Lemaster

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

How do you change the reply in AAD? Where? From what to what? Also, AAD is an enterprise concern, but the failure may belong to a single app, not all of them. – Goatish

Answer 7

I noticed this error when running IIS Express in the background when I had switched to hosting in full IIS. When I disabled the IIS Express, my error went away.

Publus

this was my fix too, except i added the IIS Express certificate (which is in IIS) to the https binding for Default Web Site in IIS, then I was using all https traffic, even localhost, and that fixed it – Ruination

Answer 8

A cookies rewrite rule in the web.config to ensure samesite cookies gave this cryptic exception. Disabling that rule solved it.

Brawn

Can you elaborate on what that means? – Paprika

Answer 9

A temporary solution which worked for me for an app secured via Azure Active Directory was to signout (by going to the sites/Account/SignOut page) and then I was able to return to the home page and sign in ok. Hope this helps someone.

Necaise

Answer 10

For me it was a different problem. My site was working with both of the urls below

https://www.example.com and https://example.com

But my redirect url was https://www.example.com.

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
            {
                ClientId = ConfigurationManager.AppSettings["ClientId"].ToString(),
                Authority = ConfigurationManager.AppSettings["Authority"].ToString(),
                RedirectUri = ConfigurationManager.AppSettings["RedirectUri"].ToString();//https://www.example.com 
    }

Users who use https://example.com the mentioned exception occurs.

The cookie generated for www.example.com and example.com are different. So after the login when it redirects, the cookie doesn't contain the correct nonce to validate and the exception occurs.

The solution for the problem is to set the redirect URL dynamically

  app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
                {
                    ClientId = ConfigurationManager.AppSettings["ClientId"].ToString(),
                    Authority = ConfigurationManager.AppSettings["Authority"].ToString(),
                    RedirectUri = ConfigurationManager.AppSettings["RedirectUri"].ToString(),//https://www.example.com 
,

                // sample how to access token on form (when adding the token response type)
                Notifications = new OpenIdConnectAuthenticationNotifications
                {
                    
                    RedirectToIdentityProvider = async n =>
                        {
                            var uri = n.Request.Uri; //From request URL determine the RedirctUri and set below
                            n.ProtocolMessage.RedirectUri =""//Set the url here
                            
                        }
                }
    }

The same issue can happen with https://www.example.com and http://www.example.com

Camiecamila

Answer 11

Users where getting this issue when Edge was set to IE compatibility mode, removed it from IE compatibility and it solved the issue. Setting / list of sites is controlled under edge://compat.

Epiphragm

Answer 12

I end up allowing the Owin to skip to the next Middleware on AuthentificationFaild callback function. I'm checking if the error message contains nonce error Id and call SkipToNextMiddleware function from the context. With that, I'm restarting the sign-in process so if the user cookies were not set there will be a second call that will set the cookie.

The code is written in vb.net

     Dim oidcAuthOpt= New OpenIdConnectAuthenticationOptions()
     oidcAuthOpt.Notifications = New OpenIdConnectAuthenticationNotifications With {
                    .AuthenticationFailed = Function(n)
                                     If (n.Exception.Message.StartsWith("OICE_20004") Or n.Exception.Message.Contains("IDX10311")) Then
                                        n.SkipToNextMiddleware()
                                        Return Task.FromResult(0)
                                     End If
                                     Return Task.FromResult(0)
                                  End Function
       }

Miserable