Which version of Microsoft Identity Web are you using?
Microsoft Identity Web 0.2.3-preview
Where is the issue?
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, @blowdart: can you please help?
So the bounce back is http://mywebsite.com/signin-oid, but you're expecting https://?
Can you capture a fiddler trace to see what's being sent as the return URL? Can you also check your site is actualling seeing the X-ForwardedFor and Proto headers, and share your complete startup.cs (with any secrets removed), as ordering is important with middleware, and we can't see what order you've added things in.
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.
---> MSAL.NetCore.4.16.1.0.MsalServiceException:
ErrorCode: invalid_client
Microsoft.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
You're right, it's strange that you've set the RedirectUri but that's not what shows up in the error message. That's a question for AAD.
However, you shouldn't need to set RedirectUri if the forwarders are right, it will be auto-generated with the correct scheme. See the troubleshooting guide for figuring out what forwarded headers your proxy is actually sending.
@mia01 is your question answered?
@jennyf19 I'm looking into setting up https redirection which I think might resolve it on our end since I realised this issue only happens when I load the app on http to begin with. In the meantime I've found adding this seems to help:
In the Startup.cs Configure() method
app.Use((context, next) =>
{
context.Request.Scheme = "https";
return next();
});
@Tratcher FYI, see @mia01's response above. thanks.
@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
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();
Most helpful comment
@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