by: jayanth.kurupPosted on:

Error IDX21323 – RequireNonce is ‘[PII is hidden by default. Set the ‘ShowPII’ flag in IdentityModelEventSource.cs to true to reveal it.]

Error IDX21323 – RequireNonce is ‘[PII is hidden by default. Set the ‘ShowPII’ flag in IdentityModelEventSource.cs to true to reveal it.]

One of the best features of Azure is the ability to authenticate with Azure Active Directory. This is easy to implement and therefore a very nice way to implement authentication without the hassle of additional database tables etc. Recently while implementing this solution, we encountered a unique scenario where we got the below error message.

Error IDX21323 – RequireNonce is ‘[PII is hidden by default. Set the ‘ShowPII’ flag in IdentityModelEventSource.cs to true to reveal it.]

The issue was related to a cookie that was being reset during the authentication process. The error message didn’t give much information about why this was happening and while Googling we did find a number of websites with various number of solutions none of which seem to be working. This included adding NuGet packages, running fiddler to identify what kind of cookie is being set , adding login in StartupAuth.cs file and even changing Google Chrome flags. What we identified was that session management was being implemented using the local DB with ASP. Net and in the absence of that table structure being available locally we got the error message.

 

This was because mainly while setting the database connection string we had commented out the connection string for local DB. Local DB is a database that is installed by default and if you have the connection string in web config you will notice that it points to a standalone database inside which certain tables have been created to store session level information instead of being stored in cookies. While creating the website we had commented out the connection string to local DB because we assumed we wouldn’t need it.

The only connection string available in web config was the one that pointed to the user database. As a result of browser settings as well as the way that the app was created session information was not being stored anywhere. During authentication the nonce key was being looked for and wasn’t found and as a result we kept getting the error message. This often happens after the authentication process is complete and redirect is happening to the secure HTTPS page. To circumvent the issue, we created inside the user database to store session information and this automatically resolved the issue that we were facing.

This is the table structure you need to create

CREATE TABLE [dbo].[UserTokenCaches](
    [UserTokenCacheId] [int] IDENTITY(1,1) NOT NULL,
    [webUserUniqueId] [nvarchar](max) NULL,
    [cacheBits] [varbinary](max) NULL,
    [LastWrite] [datetime] NOT NULL,
 CONSTRAINT [PK_dbo.UserTokenCaches] PRIMARY KEY CLUSTERED 
(
    [UserTokenCacheId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Followed by editing the web.config to set the connection string for the configuration shown below, update CAPITAL Items with appropriate values.

<add name=”DefaultConnection” connectionString=”Data Source=SERVERNAME;Initial Catalog=DBANAME ;User ID=DBUSERNAME ;Password=DBPASSWORD” providerName=”System.Data.SqlClient” />

The above solution worked for us simply because we were missing a cookie handling mechanism by default. Ensure you are facing the same issue before proceeding.

EDIT:- Another reason this occurs is because the identity provider (azure ad for example) is returning the user to a different url than what is expected. e.g the connection started in http and redirected to https. in our case we were using self signed certificate and the binding for the site in IIS was pointing to all Unassigned instead of the local IP of the machine. In this case we had hard coded the local IP of the machine as the URL the user needed to redirect to after authentication via Azure AD. So we need to ensure the IP the site is bound to in IIS matches that of the redirect URL from Azure AD. The url being used in Azure AD can be found in the web.config file of your site.

Leave a Reply