IDX21323 - RequireNonce is true, Nonce was null

We have multiple clients configured with Azure Active Directory (Microsoft Entra) for requiring authentication when accessing their website. The majority of them is only for protecting the backoffice (CMS admin), but we have certain of them that uses it for protecting the whole site.

There is existing Optimizely documentation that allow you to setup your site to use AAD authentication, but it doesn't talks about the famous issue certain people are having when signing in to the website; "IDX21323 - RequireNonce is true, Nonce was null". I might come with a surprise, but this issue will be occurring systematically under all DXP environments if you do not ask Optimizely to change a setting under Cloudflare for you. The problem is described there: https://support.optimizely.com/hc/en-us/articles/7492181419789-Nonce-Error-Using-OpenIdConnect-for-Authentication-with-DXC.

The solution though is something that doesn't seems to ring a bell for certain people. As of the time of writing, it says "to bypass the origin cache control", but in contrary, the mentioned page rule is enabling Cloudflare to respect the origin cache control header. You see, it is not entirely respecting cache-control directive from the origin server, by default. Organizations with an enterprise plan with Cloudflare are all having the rule disabled by default. Something which is hard to understand as Cloudflare's documentation doesn't really give up insights on that matter except in the previous thread. It means that even if you've decided to put any custom cache-control directives within your application, Cloudflare will ignore some of them or will behave differently.

This default setup can cause a couple of different issues:

• Signing in under certain URLs/paths, the Nonce cookie isn't setup during the authentication, thus causing the IDX21323 issue.
• Leaving certain assets "publicly" available after someone has loaded it once, even though it should require authentication, because it isn't validating it once the Edge has cached the asset.
• Breaking images because the Edge has cached the authentication redirection action, a http 302 status code.
• Preventing your application to set request cookies. Cloudflare will sometimes, under specific scenarios, completely discard the cookie before sending the response to the client.

Don't get me wrong, caching is important, but you need to adapt certain rules depending on what your website is. For intranet sites by example, it's important that the caching doesn't break the experience nor expose certain privately accessible assets. There's a couple of tricks you can apply right up front, by example, when using the extension method AddOpenIdConnect, you can control the Cache-Control header only when redirecting to the authentication provider.

All in all, though, take a good attention of how your website is behaving when hosted under Optimizely DXP, especially when you are protecting certain areas, more than the CMS backoffice itself. Normally any Optimizely CMS solution will include right out of the box optimized cache control headers, especially for assets, but keep in mind that Cloudflare will react differently with them since the page rule "Origin Cache-Control" is not enabled by default (for enterprise customers only).