AuthorizationCodeReceived event not firing - asp.net-mvc

Question

I'm attempting to implement the OpenId Connect middleware in a an ASP.NET MVC 5 (.Net Framework) application.
In my AccountController.cs I send an OpenID Connect sing-in request. I have another OpenId connect middleware implemented which is why I specify that the middleware I want to challenge against is "AlternateIdentityProvider".
public void SignIn()
{
HttpContext.GetOwinContext().Authentication.Challenge(
new AuthenticationProperties { RedirectUri = "/" },
"AlternateIdentityProvider");
}
Upon issuing a challenge against the middleware, the RedirectToIdentityProvider event in Startup.cs fires and I am redirected to the provider for sign in. However, after successfully signing in I am redirected to the specified redirect uri with the state and code parameters added as query parameters i.e. http://localhost:63242/singin-oidc/?state=State&code=AuthorizationCode (parameters removed for brevity), which results in a 404 as no such route exists in my application.
Instead I expected the successful signin to trigger the AuthorizationCodeReceived event where I can implement my additional logic. In fact none of the other events ever trigger.
I have implemented an almost identical solution in ASP.Net Core 2.1 and here I am able to step through the different events as they trigger.
The relevant code of my current Startup.cs is shown below. Note that the OpenId provider throws an error if the inital request include reponse_mode and some telemetry parameters, hence these are removed during the initial RedirectToIdentityProvider event.
Any ideas why the callback from the OpenId provider is not getting picked up in the middleware?
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions("AlternateIdentityProvider")
{
ClientId = { { Client Id } },
ClientSecret = { { Client Secret } },
Scope = OpenIdConnectScope.OpenId,
ResponseType = OpenIdConnectResponseType.Code,
RedirectUri = "http://localhost:63242/singin-oidc",
MetadataAddress = { { Discovery document url } },
Notifications = new OpenIdConnectAuthenticationNotifications
{
RedirectToIdentityProvider = context =>
{
Debug.WriteLine("Redirecting to identity provider for sign in..");
context.ProtocolMessage.EnableTelemetryParameters = false;
context.ProtocolMessage.ResponseMode = null;
return Task.FromResult(0);
},
AuthorizationCodeReceived = context => {
Debug.WriteLine("Authorization code received..");
return Task.FromResult(0);
},
SecurityTokenReceived = context =>
{
Debug.WriteLine("Token response received..");
return Task.FromResult(0);
},
SecurityTokenValidated = context =>
{
Debug.WriteLine("Token validated..");
return Task.FromResult(0);
},
}
});

Answer 1

I was encountering the same issue. I am trying to plug in Owin into our legacy WebForms app.
For me, I had to do the following:
1) Change the application manifest of the application definition on Azure to set the "oauth2AllowIdTokenImplicitFlow" property to true from false.
Go to the Azure Portal,
Select to Azure Active Directory
Select App Registrations
Select your app.
Click on Manifest
Find the value oauth2AllowIdTokenImplicitFlow and change it's value to true
Click Save
2) In your startup.cs file, change the following:
ResponseType = OpenIdConnectResponseType.Code
to
ResponseType = OpenIdConnectResponseType.CodeIdToken
Once, I did those two things, the SecurityTokenValidated and AuthorizationCodeReceived started firing.
Though, I am not sure this is the right way to go or not. Need to do more reading.
Hope this helps.

Answer 2

Please be aware that the OpenId Connect implementation in .Net Framework only support response_mode=form_post. (See closed GitHub issue)
Since you strip the parameter in the request to the OpenId Connect provider (in your RedirectToIdentityProvider notification), then the provider will default to response_mode=query pr. the specs. (see relation between response_type and response_mode ind the specs.)
So in short the OpenId Connect middleware expects that there will come a HTTP POST (with a form body) and your provider will properly send a HTTP GET (with parameters as query-string).