If your application is not able to authenticate using Azure AD, you may come across to this error message: “IDX10311: RequireNonce is ‘true’ (default) but validationContext.Nonce is null“.
Here is the full error message:
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’.
If you are receiving a Content Security Policy error related to the nonce directive, check this post out: Dynamic scripts with CSP (Content Security Policy)
Background
The nonce parameter is a hard-to-guess value that OpenID Connect uses for mitigating token replay attacks. Here’s how it works:
- The client generates a nonce value and includes it in the request. It saves that value in a cookie with a unique name (so that the original nonce value will be available later, during the last leg of the authentication flow). The cookie is protected by server-driven cryptography and cannot be forged or tampered with by a client
- When
the app eventually receives an id_token, it searches among its claims for a
nonce claim and verifies that it contains the original nonce value communicated
in the request. For the middleware, that’s an easy task, given that the same
value is available in the mentioned cookie. An attacker who somehow stole an
id_token
would not be able to pass this test, given that he or she would not be able to craft the corresponding cookie. This is a necessary security measure. However, It may occasionally cause expected errors. Any scenario in which cookies are somehow deleted or otherwise altered in the time between the sign-in request and the response will cause the authentication to fail, given that the nonce check relies on them
The reason why “IDX10311: RequireNonce is ‘true’ (default) but validationContext.Nonce is null” error occurs is that a cookie is missing or altered during the authentication with AAD.
This issue might be perfectly expected for certain scenarios such as
- Using browser’s Back button
- Trying to login after a long time of inactivity
- Using the site in multiple tabs
If the scenario one of these cases, the best way to proceed is to implement a code block to catch this exception and inform/redirect the user accordingly.
Environment and Settings
Here are more details about the server and issue:
- The issue occurs in IE11, Edge, and Chrome
- All users are affected
- Application is hosted by Azure App Service
- No SSL warnings or errors (Related issue)
- Visual Studio 15.9 and .NET Framework 4.5.2 are used
- The same code block for authentication was used in different apps and no issues are observed for them
Solution for IDX10311: RequireNonce is ‘true’ error
In my case, the issue occurred because the claim policy was not applied to the App Registration in Azure AD. Applying the policy fixed the issue. If this doesn’t solve the issue in your case, please try the following steps:
- Check if “Home page URL” and “Reply URL” are the same on Azure portal
- Add the site address to Intranet Zone and Trusted Sites in Internet Explorer
- Check if the application has multiple redirections
- Delete cookies on the client side and restart Azure site (not a permanent solution but helps to narrow down the issue)
- Check “Cookie restriction policy” on the browser side (Related issue)
- Collect Fiddler trace and check nonce cookies
If you want to build a sample project quickly to test Azure AD authentication by using OpenID Connect, check this out.
Hi and thanks for the article, very interesting. Just a question: when you said “Applying the policy fixed the issue” to which kind of policy are you referring? Can you please explain better your solution policy related?
Thanks again.
Hi Max, thanks for stopping by! Here is a link about claims and claim policies:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-enterprise-app-role-management