OpenIdConnectProtocolValidationContext.Nonce was null

Question

HI can someone please help imgetting below error when calling outlook rest api

IDX21323: RequireNonce is '[PII is hidden by default. Set the 'ShowPII' flag in IdentityModelEventSource.cs to true to reveal it.]'. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'. Note if a 'nonce' is found it will be evaluated.

Lederhosen

I am facing the same issue, is there any solution for this? – Photozincography

Are either of you able to post your solutions if you managed to fix it - am experiencing the same problem – Levinson

Did you get a solution for this? I'm having this issue as of today: https://mcmap.net/q/586547/-mvc5-azure-ad-idx21323 – Continual

I got in to same issue any poosible solution? – Acumen

Answer 1

aka IDX21323 points towards losing the nonce cookie (set by the initial Challenge call). Inspect your initial SignIn call (or WebForms postback SignIn) and confirm that you have a OpenIdConnect.nonce cookie actually set (Chrome network tab).

If not, I suspect that you have the same issue we had, which is that the OWIN Middleware sets the cookie, but its content gets accidentally overwritten by some other cookie modifications of your legacy application. This is very likely a bug of the OWIN middleware (see ASP.NET_SessionId + OWIN Cookies do not send to browser), as it handles cookies through its own OwinContext and Cookie representation implementation, which is not in sync with the standard HttpContext.

How to fix when you have the initial nonce cookie missing: We avoided any cookie changes during the SignIn request -> therefore the OWIN middleware can read/write its cookies with no interference.

Heterogenous

Answer 2

When setting the nonce cookie running on localhost (non-secure) in a Chromium based browser, it's blocked because of SameSite=none and it not being secure. The fix for this case is to change localhost to use SSL (use https on asp.net application running on localhost) and update the Azure AD redirect URL to match.

Trinidadtrinitarian

Answer 3

In a WebForms app I got the same error when I used my machine name in the project url, but used "localhost" as my login redirect url. When I set them both to localhost the problem went away.

Leesaleese

Answer 4

If your tenant was created on or after October 22nd, 2019, it’s possible you are experiencing the new secure-by-default behavior and already have security defaults enabled in your tenant.

How to Fix :- goto your Azure AD account => properties => on tab Access management for Azure resources => enable this tab to Yes.

Sextet