[Bug] Reply address does not match the reply address provided when requesting authorization

Which version of Microsoft Identity Web are you using? Microsoft Identity Web 0.2.3-preview

Where is the issue?

• Web app
  • Sign-in users
  • Sign-in users and call web APIs
• Web API
  • Protected web APIs (validating tokens)
  • Protected web APIs (validating scopes)
  • Protected web APIs call downstream web APIs
• Token cache serialization
  • In-memory caches
  • Session caches
  • Distributed caches
• Other (please describe)

Is this a new or an existing app? a. The app is in production and I have upgraded to a new version of Microsoft Identity Web.

Repro I’m getting frustrated by an error which occurs on a .netcore3.1 app I’m working on. Here’s my setup:

In Startup.cs

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftWebApp(options =>
    {
        Configuration.Bind("AzureAd", options);
        options.Events ??= new OpenIdConnectEvents();
        options.Events.OnRedirectToIdentityProvider = async ctx =>
        {
            ctx.ProtocolMessage.RedirectUri = Configuration["AzureAd:RedirectUri"];
            await Task.CompletedTask;
        };
    })
    .AddMicrosoftWebAppCallsWebApi(Configuration, new[] { "user.read" })
    .AddDistributedTokenCaches();

In my appsettings

"AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "ClientId",
    "TenantId": "TenantId",
    "RedirectUri": "https://mywebsite.com/signin-oidc",
    "ClientSecret": "ClientSecret"
  },

the azure app registration is configured correctly with https://mywebsite.com/signin-oidc as the redirect url. I’ve also added the following to allow headers to be forwarded from the proxy:

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

// then in the Configure method

app.UseForwardedHeaders();

Yet I’m still getting this error which is baffling me. I thought by adding

ctx.ProtocolMessage.RedirectUri = Configuration["AzureAd:RedirectUri"];

I would overcome this but it seems to have no impact. I’ve checked the authorise request url in the browser and the redirect_uri parameter is set correctly to https://mywebsite.com/signin-oidc

Yet still I’m getting this error in my logs:

An unhandled exception occurred","Properties":{"CorrelationId":"c3393560-6ebe-41ce-99fc-693c1a387474","Path":"/signin-oidc","Method":"POST","exceptionMessage":"An error was encountered while handling the remote login.","exception":"System.Exception: An error was encountered while handling the remote login.\n ---> MSAL.NetCore.4.16.1.0.MsalServiceException: \n\tErrorCode: invalid_client\nMicrosoft.Identity.Client.MsalServiceException: A configuration issue is preventing authentication - check the error message from the server for details.You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details.  Original exception: AADSTS500112: The reply address 'http://mywebsite.com/signin-oidc' does not match the reply address 'https://mywebsite.com/signin-oidc' provided when requesting Authorization

Any help would be very much appreciated

Thanks!

[Tratcher]

@mia01 https redirection is the way to go. The workaround you’ve show should only be applied in https reverse proxy scenarios, not to requests that are really http.

HTTPS redirection is covered here: https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-3.1&tabs=visual-studio

[mia01]

Some follow-up info in case it might help someone. We had a reverse proxy which was terminating the ssl. Our development environment was forwarding the https scheme but the production environment wasn’t which caused additional confusion. Once I had updated the production environment and made sure we were forwarding the scheme and also made sure https redirection was in place this issue disappeared and I no longer had to use this:

            app.Use((context, next) =>
            {
                context.Request.Scheme = "https";
                return next();
            });

Nor did I need to manually set the redirect like this:

ctx.ProtocolMessage.RedirectUri = Configuration["AzureAd:RedirectUri"];

All I needed was the section which told the app to use forwarded headers:

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

// then in the Configure method

app.UseForwardedHeaders();