This project has moved and is read-only. For the latest updates, please go here.
4

Closed

Support Authorization Code Flow and more response_modes in OpenIdConnectAuthenticationMiddleware

description

Support Authorization Code Flow and the traditional response_modes in OpenIdConnectAuthenticationMiddleware, so that interoperability is increased.

Comment: The current preview of OpenIdConnectAuthenticationMiddleware is great but it seems to "just" support the implicit flow and the response_mode form_post.
Closed Jul 15, 2014 at 5:42 PM by Tratcher
This is on our roadmap for vNext, but that will be executed on in a different code base.

comments

PinpointTownes wrote Jun 7, 2014 at 6:43 PM

As stated, the OIDC client only works with POST callback due to the first bits of AuthenticateCoreAsync and thus needs the OIDC server to support the Form Post Response Mode extension :
OpenIdConnectMessage openIdConnectMessage = null;

// assumption: if the ContentType is "application/x-www-form-urlencoded" it should be safe to read as it is small.
if (string.Equals(Request.Method, "POST", StringComparison.OrdinalIgnoreCase)
  && !string.IsNullOrWhiteSpace(Request.ContentType)
    // May have media/type; charset=utf-8, allow partial match.
  && Request.ContentType.StartsWith("application/x-www-form-urlencoded", StringComparison.OrdinalIgnoreCase)
  && Request.Body.CanRead)
{
    if (!Request.Body.CanSeek)
    {
        // Buffer in case this body was not meant for us.
        MemoryStream memoryStream = new MemoryStream();
        await Request.Body.CopyToAsync(memoryStream);
        memoryStream.Seek(0, SeekOrigin.Begin);
        Request.Body = memoryStream;
    }

    IFormCollection form = await Request.ReadFormAsync();
    Request.Body.Seek(0, SeekOrigin.Begin);

    // Post preview release: a delegate on OpenIdConnectAuthenticationOptions would allow for users to hook their own custom message.
    openIdConnectMessage = new OpenIdConnectMessage(form);
}

if (openIdConnectMessage == null)
{
    return null;
}
We should strongly consider improving that. That said, it would largely increase the number of requests susceptible of being buffered when no CallbackPath has been provided. Maybe we should simply remove buffering and make CallbackPath mandatory, just like the other authentication handlers?

PinpointTownes wrote Jun 7, 2014 at 7:48 PM

Apparently, leaving CallbackPath optional is needed to support IDP-initiated flow. As this is a rare case, maybe it should just be disabled by default to avoid reducing performance of every request when it's not really needed?

BrentSchmaltz wrote Jun 10, 2014 at 5:20 PM

We are only going to support id_token and id_token + code for V1.
But we need Query as an option, with default as Form_Post. We should have a BFA comment indicating that Query is less secure that FORM_POST.

manfredsteyer wrote Jun 10, 2014 at 6:07 PM

Hi Brent,

great to hear that. In this case, this canceled contribution could come in handy: [1]. I've canceled it in favor of another hook-based solution, when you told me, that Query is not an option ...

Wishes,
Manfred

[1] http://katanaproject.codeplex.com/SourceControl/network/forks/manfredsteyer/Issue247/contribution/6649

manfredsteyer wrote Jun 11, 2014 at 11:48 AM

And now, there is one more (very small) pull-request, that just does, what Brent is suggesting above:
https://katanaproject.codeplex.com/SourceControl/network/forks/manfredsteyer/Issue247c/contribution/6967

manfredsteyer wrote Jun 21, 2014 at 12:54 PM

Tratcher wrote Jun 21, 2014 at 3:33 PM

Thanks for all the submissions. Please close any old pull requests you no longer want considered.