Nonce Error Using OpenIdConnect for Authentication with DXC


I am using OpenIdConnect for authentication against Azure in DXC and it works fine. However, if I try to link directly to an asset (image, document, etc.. ) before authenticating I get the following error

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 I authenticate first and then hit the link it works fine. I can't reproduce it using my local machine running IISExpress.

Can anyone else using OpenIdConnect validate that they are having the same issue. 


#194998 Jul 11, 2018 1:20
  • Antti Alasvuo
    Member since: 2010

    Hi Michael,

    Can you first clarify us that the asset url is not the edit url, so something like this: [YOUR-HOST-HERE]/EPiServer/CMS/Content/globalassets/en/alloy-meet/alloymeet.png,,61_62?epieditmode=False BUT url is like this: /globalassets/alloy-meet/alloymeet.png when trying to acces an asset not logged in.

    If the url is not edit but the "real public url", do you get the RequireNonce even if trying to access an asset with another browser in private mode (just to rule out possible cookies from bad / aborted logins using OIDC)?

    This is an old posting issue with IdentityServer3 (from year 2015) but there is the same issue and if scroll to the point where Kentor.OwinCookieSaver is mentioned it had fixed eventually the issue for the reporter of the issue.

    We are still using the Kentor.OwinCookieSaver in our OIDC implementations, so you would need to add the package to your solution and add this to your OWIN startup Configuration method before any OWIN stuff:


    Kentor.OwinCookieSaver GitHub project:

    #195012 Jul 11, 2018 10:05

    Thanks for the reply Antti.

    I am using the "real public url" and I have been testing with the browser in private mode. I have tried the OwinCookieSaver in the past and no luck. I see that the cookie is not being set that I am authenticated but I am not sure why.


    #195038 Jul 11, 2018 17:07
  • Johan Kronberg
    Member since: 2005

    I'm assuming the assets are "protected" and don't have read access for Everyone?

    #195223 Jul 17, 2018 23:13

    Correct. If I use the address that EPiServer gives me it seems to work fine. However, if I use our custom domain name it does not work.

    #195224 Jul 17, 2018 23:15
  • Johan Kronberg
    Member since: 2005

    I think that hostname is without Cloudflare CDN so it probably has something to do with that. You can try hosts file to the IP of the dxccloud name and validate that it is a CDN issue and not something with your app configuration.

    #195227 Jul 18, 2018 8:06

    We are using DXC. My understanding is the Host entry would not affect us.

    #195358 Jul 20, 2018 17:21
  • Michael Krag
    Member since: 2013

    Hi Michael

    I have the same problem. Did you find a solution?

    #201895 Mar 06, 2019 13:23

    We did find a solution to the problem. It was something to do with the CDN.

    From EPi.. 
    "Product Development Engineers mentioned that they are looking at a code change for not stripping the set-cookie for requests with CF-Cache-Status: BYPASS."  

    "Cloud Flare has deployed a fix for your issue so they will no longer be stripping the cookie but a config change does need to be made to your DXC environment which will be taken care of engineering. Here is the response I just got from them:

    Cloudflare has deployed their bugfix now, "CF-Cache-Status: BYPASS" will have the cookies sent through. Things that are not cached but still sent through the caching-infrastructure on their end, resulting in "CF-Cache-Status: MISS" will still not have any cookies sent through.
    For this to work, "Origin Cache Control: On"-pagerule can applied to the customers zone now to make pages with "Cache-Control: private" headers bypass the Cloudflare cache completly, which would result in "CF-Cache-Status: BYPASS" and let through the authentication-cookies.

    So engineering will be updating your Cloud Flare page rules to set "Origin Cache Control: On" which will finish the fix, once I get word this change is complete I will let you know.

    So the change was made and it fixed it for us so I would contact EPi Support. However, we are experiencing some other issues that I am not 100% sure are not related to this. We are still working with EPi on a ticket but to this point we don't have a resolution.


    #201937 Mar 07, 2019 16:14