OWIN OpenIdConnect Middleware IDX10311 nonce canno

问题:

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.

回答1:

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

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

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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

回答7:

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.