I am having an issue with a .NET core web app utilizing OpenID for AD authentication. Currently in my application settings the CallBackPath is set to /signin-oidc
"Authentication": {
"AzureAd": {
"AADInstance": "microsoftonlinecom/",
"CallbackPath": "/signin-oidc"
and on azure the replyurl is set to azurewebsitescom/signin-oidc
Whenever I change the replyurl to localhost:44320/signin-oidc and I debug locally, it works perfectly but on Azure I get the following error:
azurewebsitesnet/.auth/login/aad/callback' does not match the reply addresses configured for the application: '
as you can tell its using the incorrect replyurl and I am not sure why it will not use the proper one that is clearly set in the replyurl settings.
startup.cs:
app.UseCookieAuthentication();
app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
{
ClientId = Configuration["Authentication:AzureAd:ClientId"],
Authority = Configuration["Authentication:AzureAd:AADInstance"] + Configuration["Authentication:AzureAd:TenantId"],
CallbackPath = Configuration["Authentication:AzureAd:CallbackPath"],
PostLogoutRedirectUri = Configuration["Authentication:AzureAd:PostLogoutURL"],
SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme
});
Also if I add a wildcard reply URL e.g. exampleazurewebsitesnet/* then I am able to authenticate against my application except it states I do not have access and the replyurl is still the incorrect one from above: azurewebsitesnet/.auth/login/aad/callback
"You do not have permission to view this directory or page."
I was forced to intentionally input incorrect URLs since I do not have enough authority to post more than 2 links on stack overflow
To add redirect URIs with an HTTP scheme to app registrations that sign in work or school accounts, use the application manifest editor in App registrations in the Azure portal. However, though it's possible to set an HTTP-based redirect URI by using the manifest editor, we strongly recommend that you use the HTTPS scheme for your redirect URIs.
In order to avoid customers to have to update the redirect URI in the code when they deploy their Web apps, the redirect URI is computed automatically by ASP.NET Core (part of the auth code flow), and also by Microsoft.Identity.Web (in TokenAcquisition.BuildConfidentialClientApplicationAsync ).
The openIDConnect redirect URI is computed by ASP.NET Core, but can be overriden by subscribing to the OpenIdConnect OnRedirectToIdentityProvider event and by setting the context.ProtocolMessage.RedirectUri property to the desired redirect URI. Same problem for the post logout redirect URI used in global sign-out.
Infinite redirect between OpenID Connect Application and Azure AD July 29, 2019July 31, 2019Bac Hoang [MSFT] Recently I came across an interesting infinite redirection problem between an OpenID Connect (OIDC) Application and Azure AD as demonstrated in the Fiddler screen shot below.
Based on the redirect URL, it seems that you enable the Authentication/Authorization feature provide by Azure App service after you deploy the web app on Azure. There is no need to config it since you have implement the authentication in the web app. You can disable it via the new Azure portal like figure below:
More detail about this feature you can refer here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With