Using OWIN & OpenId to authenticate users for my basic web application using Azure Active Directory, as described in the Readme.md in Microsoft's sample project here:https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
The following item is in my web.config:
<add key="ida:PostLogoutRedirectUri" value="https://localhost:44320/" />
The Startup.Auth is as follows:
private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"];
private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
private static string postLogoutRedirectUri = ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"];
string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);
public void ConfigureAuth(IAppBuilder app)
{
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = clientId,
Authority = authority,
PostLogoutRedirectUri = postLogoutRedirectUri,
RedirectUri = "https://localhost:44320/Home/About",
Notifications = new OpenIdConnectAuthenticationNotifications
{
AuthenticationFailed = context =>
{
context.HandleResponse();
context.Response.Redirect("/Error?message=" + context.Exception.Message);
return Task.FromResult(0);
}
}
});
}
}
However the microsoft.com website does not redirect even though the redirect URI made it into it's URL
I spent a lot of time properly figuring out how to get this to work. Even though 3 years ago we just didn't bother. There seemed to be a lot of people on the internet with this issue and I wanted to make sure this is answered for everyone.
The solution below applies for the issue occurring for a standard Azure AD. It also applies to Azure AD B2C, in the circumstance where you sign in with an organizational account. (Note that this solution does not cover the new b2clogin URIs and user flow technique, as it didn't exist at the time that I asked the question)
The URI you are using as a post logout redirect must be specified in both the reply URLs and as the Front Channel Logout URL. Normally front-channel logout is a silent request that the IDP sends to your application to allow you to run logic to clear cookies, but doesn't cause a redirect. But it seems to also serve a purpose when post logout redirect is specified and must be identical: Be careful of accidentally adding trailing slashes at the end of your URIs. They must be perfectly identical here and in your client application.
An authority of the form https://login.microsoftonline.com/<org-name>.onmicrosoft.com/V2.0
will not work. For a standard Azure AD I had to change the authority to be of the form https://login.microsoftonline.com/<tenant-id>/V2.0
for a specific tenant or https://login.microsoftonline.com/common/V2.0
which is also used in some scenarios I think.
For B2C AD tenants it only works for the common
endpoint above.
Side note 1: with the common
endpoint you have to set ValidateIssuer
to false in the token validation parameters or you will get an exception. Doing the validation correctly is outside the scope of this SO question.
Side note 2: When searching for this issue on Google you might come across some solutions to the problem for people authenticating against Identity Server. The solutions and the specification suggest you to add an id_token_hint to your signout request. This was neither sufficient nor necessary for me to get the redirect working for Azure AD.
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