[Bug] Using AAD B2C in aspnetcore 3.0 behind Azure FrontDoor results in login exception (no correlation cookies in response)

Which Version of MSAL are you using ?

MSAL 4.3.0

Platform netcore 3.0

What authentication flow has the issue?

• Web App
  • Authorization code

Other? - please describe;

Is this a new or existing app? c. This is a new app or experiment App is in development testing, but not yet prod

Repro

/// appsettings.json
{
  "Authentication": {
    "AzureAdB2C": {
      "ClientId": "00000000-0000-0000-0000-000000000000",
      "Domain": "devlocal.b2clogin.com",
      "Tenant": "devlocal.onmicrosoft.com",
      "GraphUri": "https://graph.microsoft.com/",
      "GraphRelativePath": "v1.0/users",
      "SignUpSignInPolicyId": "b2c_1_susi",
      "ResetPasswordPolicyId": "b2c_1_reset",
      "EditProfilePolicyId": "b2c_1_edit_profile",
      "RedirectUri": "https://localhost:44387/signin-oidc",
      "ClientSecret": "980234jkl2j34k2349"
    },

/// csharp

            public void Configure(string name, OpenIdConnectOptions options)
            {
                options.ClientId = AzureAdB2CSettings.ClientId;
                options.Authority = AzureAdB2CSettings.Authority;
                options.UseTokenLifetime = true;
                options.TokenValidationParameters = new TokenValidationParameters { NameClaimType = "name" };

                options.Events = new OpenIdConnectEvents
                {
                    OnRedirectToIdentityProvider = OnRedirectToIdentityProvider,
                    OnRemoteFailure = OnRemoteFailure,
                    OnAuthorizationCodeReceived = **OnAuthorizationCodeReceived**,
                    OnTokenValidated = OnSecurityTokenValidated,
                    OnMessageReceived = OnMessageReceived
                };
            }

            private async Task OnAuthorizationCodeReceived(AuthorizationCodeReceivedContext context)
            {
                string signedInUserId = context.Principal.FindFirst(ClaimTypes.NameIdentifier).Value;

                var app = ConfidentialClientApplicationBuilder.Create(AzureAdB2CSettings.ClientId)
                    .WithB2CAuthority(AzureAdB2CSettings.Authority)
                    .WithRedirectUri(AzureAdB2CSettings.RedirectUri)
                    .WithClientSecret(AzureAdB2CSettings.ClientSecret)
                    .Build();

                new MsalStaticCache(signedInUserId, context.HttpContext).EnablePersistence(app.UserTokenCache);

                try
                {
                    var accounts = await app.GetAccountsAsync();
                    var result = await app.AcquireTokenSilent(AzureAdB2CSettings.ApiScopes.Split(' '), accounts.FirstOrDefault())
                        .ExecuteAsync();
                    context.HandleCodeRedemption(result.AccessToken, result.IdToken);
                }
                catch (MsalServiceException ex)
                {
                    Logger.LogError(ex.Message);
                }
            }

Expected behavior I’ve got an aspnetcore 3.0 web app that uses Azure B2C. In dev it has been deployed to an Azure web app and works as expected with Azure B2C and MSAL. We can use it with a custom domain name and get the result we want. I.e.

• user clicks on the Sign In link
• they are redirected to the MS B2C site and can sign in as expected (2FA via text message is enabled)
• After they have been authenticated, they are redirected back to our site

in the request that works (either using local debugging or i deploy the website without FrontDoor to Azure), i see these cookies:

Actual behavior However, when the same site is deployed behind an Azure FrontDoor, the redirect back from Azure B2C doesn’t contain the aspnet correlation cookies. This results in a Correlation Failed error

In this scenario, i don’t see the aspnetcore correlation cookies in the response.

Possible Solution

We logged this via a support request on Azure and were directed to an engineer for debugging and review.

He suggested that we need to somehow instruct our app to send heads to FrontDoor to instruct it not to cache the response that comes back after authentication. He recommended: Cache-Control: private.

The question is, as it is MSAL that is performing the signin request on our behalf, how can we send those headers as part of the request? I’m not sure whether this is a bug report or a feature request as I can’t find any documentation which describes how to do this.

Possibly there could be some options/parameters/settings on this object method?

ConfidentialClientApplicationBuilder.Create

Additional context/ Logs / Screenshots Add any other context about the problem here, such as logs and screebshots. Logging is described at https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/logging

[EdiWang]

I solved the problem by removing the default host header in Azure Front Door backend pool. See my blog post: https://edi.wang/post/2020/6/29/solving-azure-ad-sign-in-failure-with-azure-front-door

[kylepope-ge]

@ossentoo We are running an ASP.NET Core 3.1 server and have the exact same problem with the correlation cookie. Observing the original request to authenticate, it looks like our server is not including the correct redirect_uri query parameter as mentioned by @Zimmergren. The solution that @EdiWang documented looked promising, but because we don’t have a custom domain, going to the Front Door frontend URL results in 404 errors for us.

I’ve reviewed the link you last referenced and still wasn’t able to get it to work either. Setting the ASPNETCORE_FORWARDEDHEADERS_ENABLED app config setting to true didn’t do anything for us for whatever reason and the guide to use the Forwarded Header middleware here didn’t work either.

All that said, I found this solution here that worked. It turns out the key is to also specify ForwardedHeaders.XForwardedHost in the Forwarded Header middleware’s configuration.

Not sure if you figured this out yet or not, but hopefully this helps someone out there…