c#owinfiddleridentityserver3openid-connect

Reputation: 605

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.

Upvotes: 20

Answers (12)

emanuel

Reputation: 409

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
       }

Upvotes: -1

RickWeb

Reputation: 2105

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.

Upvotes: 0

pav

Reputation: 480

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:

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.
We added the new domain binding to the site in IIS (we're old school, but do the same for your hosting of choice 😊)
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!

Upvotes: 6

Kiran B

Reputation: 715

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

Upvotes: 0

gilm0079

Reputation: 605

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

Upvotes: 0

patrickjlee

Reputation: 250

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.

Upvotes: 0

Dirk Vermeer

Reputation: 378

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

Upvotes: 0

Marconline

Reputation: 1441

Maybe is this the cause?

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

I'm summing up my discoveries:

The problem is in the OpenIdConnect.nonce.OpenIdConnect cookie
This cookie is set from the app (let's call this "ID Client") as soon as the OpenID Middleware init an authentication session
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?)
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.
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

Upvotes: 12

Ashutosh B Bodake

Reputation: 1412

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.

Upvotes: 3

ebol2000

Reputation: 1283

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.

Upvotes: 1

Jek

Reputation: 461

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

Upvotes: 7

pau Fer

Reputation: 130

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.

Upvotes: 3

OWIN OpenIdConnect Middleware IDX10311 nonce cannot be validated

Answers (12)

Related Questions