This project has moved. For the latest updates, please go here.

OpenID Connect Auth Code Flow

Sep 10, 2014 at 11:05 PM
I'm trying to use OpenIdConnectAuthentication with an OIDC provider that does not implement the form_post response_mode. Thus using the Implicit or Hybrid flows results in a fragment response, which is a no-go for me. So I'm trying to use the Auth Code flow to at least get the auth code and then use the OnAuthorizationCodeReceived notification to get the id_token.

To do this, I'm using a response_type of "code". Per the spec the code is returned as a querystring parameter; however, the OnAuthorizationCodeReceived notification is not firing. Digging into OpenidConnectAuthenticationHandler.cs it appears that only form posts are handled.
protected override async Task<AuthenticationTicket> AuthenticateCoreAsync() {
// assumption: if the ContentType is "application/x-www-form-urlencoded" it should be safe 
 ---->      if (string.Equals(Request.Method, "POST", StringComparison.OrdinalIgnoreCase)
              && !string.IsNullOrWhiteSpace(Request.ContentType)
Am I trying to do something that Katana does not support? It is consistent with the spec, correct?
Sep 11, 2014 at 9:30 AM
You're right: response_mode=query (which is indeed the default mode for response_type=code) is not supported by the OIDC client middleware.
If you're curious, you can find the official reason in this rejected PR made by Manfred Steyer to support response_mode=query:

Anyway, your scenario wouldn't work at all because OpenIdConnectAuthenticationHandler doesn't support response_type=code either (in fact, every response_type which doesn't return an id_token). You couldn't even use the AuthorizationCodeReceived hook, because the OIDC requests are stopped very early when the handler detects there was no id_token in the payload:
// code is only accepted with id_token, in this version, hence check for code is inside this if
// OpenIdConnect protocol allows a Code to be received without the id_token
if (string.IsNullOrWhiteSpace(openIdConnectMessage.IdToken))
    _logger.WriteWarning("The id_token is missing.");
    return null;
I'd suggest either to put pressure on the Katana team (or better, on the Azure AD team...) or to fork the OIDC client middleware and manually add the basic support you need. IMHO, you shouldn't expect this very basic feature to come before ASP.NET vNext, because Katana 3 already reached RTM.

Good luck.
Marked as answer by virklba on 9/11/2014 at 8:29 AM
Sep 11, 2014 at 3:29 PM
That's what I was afraid of. I had read Manfred's discussions on the topic but didn't see that response to his pull request so thanks for the link.
Feb 24, 2015 at 1:45 PM
I wonder... doesn't accepting code only with id_token goes against the whole idea of authorization code flow? In the sense that the authorization code flow is intended to avoid the passing of tokens through the user agent?
Mar 12, 2015 at 2:39 AM
We are working on 'code' only flow. There are two scenarios we are thinking through.
  1. a pseudo identity flow - use the code to query the UserInfo endpoint.
  2. pure Server to Server.
Aug 22, 2016 at 8:17 AM
@BrentSchmaltz, @PinpointTownes

Can you give an update on this? Your last response dates back to Mar 2015.

We have a site that was built on 4.6 and uses Microsoft.Owin.Security.OpenIdConnect, Version= to for Azure AD sign in. We now have a need to integrate another authorization server that doesn't support the hybrid flow - only authorization code flow (and implicit, but we're not interested in that one).

If I am understanding the various discussions I went through correctly, we have two options:
  1. Fork Katana's OIDC middleware to support code flow
  2. Move to ASP.NET vNext where it appears to be supported
Aug 22, 2016 at 5:33 PM
Katana is pretty much dead and the chances of seeing an update for the OIDC client middleware are extremely low, IMHO.
So yeah, forking the OIDC middleware or moving to ASP.NET Core is likely what you'll have to do if you want to use the code flow.

Note: if your authorization server doesn't support OpenID Connect at all, it might be easier to fork an OAuth2-based middleware like the Google provider and create your own one. You can read the final steps of this SO post for more information.
Aug 23, 2016 at 6:41 AM
Thanks @PinpointTownes! We will have a look at whether it makes more sense to go with oauth2-based middleware or oidc.