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

Future of OpenIdConnectAuthenticationMiddleware

Apr 14, 2014 at 12:34 AM
Hi,

today I've played around with the current preview of OpenIdConnectAuthenticationMiddleware and I really like it.

I've noticed, that it currently "just" supports the Hybrid-Flow using response_mode=form_post.

I've also noticed, that it does not Exchange the received access-code for an oauth-2.0-access-token.

Now, I'm wondering, if the final version will also support Authorization Code Flow and Implicit Flow as well as the traditional response_modes using the query-string and the hash-fragment.

I'm also wondering, if the final version will also provide me with an oauth-2.0-access-token.

Can you tell me about your plans towards this?

Wishes,
Manfred
Apr 14, 2014 at 12:06 PM
Hey,

AFAICT, the hybrid flow is indeed the default one in the OIDC middleware. And while you can change the response_type via OpenIdConnectAuthenticationOptions.Response_Type, the middleware itself doesn't have the logic to retrieve an access token from an authorization code yet. That said, you can implement that using the OpenIdConnectAuthenticationNotifications.AccessCodeReceived extension point.

I think they made this choice considering that OIDC is an "authentication protocol" and not an authorization one (of course, this point could be debated during hours): as long as the identity token is retrieved, this is enough to correctly authenticate the user without having to retrieve an access token from the OIDC provider.

Concerning the implicit flow, there's no chance, IMHO, to get it implemented in the OIDC middleware: remember that it's a pure client-side flow that CANNOT be used server-side as the fragment part of the URL is never flowed to the server. Even if you started the authentication flow using the OIDC middleware, it would never get back the required payload.
Marked as answer by Manfred_Steyer on 4/14/2014 at 12:40 PM
Apr 14, 2014 at 8:45 PM
Hi,

thx for your answer. For me, it seems, that there isn't a standard-flow in OIDC and the source code of the released version looks like it just can deal with response_mode=form_post. I think for the sake of interoperability, it would be fine to support the defined flows and response_modes. And I think, it would be nice to support fetching the oauth-2.0-token out of the box, cause the combination of both, authentication and authorization, is the big advantage of OIDC (oderwhise, I could stick with OID 2 etc.).

I think, I will file an issue for this, although it isn't an issue but a pull request ...

Wishes,
Manfred
Apr 30, 2014 at 7:00 PM
I agree that there isn't a 'standard' flow in OIDC. Manfred, we exchanged thoughts about extensibility that will allow the 'query' to be easy.
We feel that 'response_mode == query' can become an issue since the id_token+code would be in the query string and could be sent to another site by the browser. FromPost mitigates this.

So look for us to review your pull request and 'query' to be pluggable.
May 1, 2014 at 12:21 AM
Hi Brent,

I see, that response_mode == query can become an issue. I'm really looking forward to hearing from you regarding my two pull-requests.

Wishes,
Manfred

p.s.: Just to prevent a misunderstanding: I wrote this post before I created the pull-request ...
May 6, 2014 at 7:46 PM
which pull request is that, I made some additional comments on 247, have a look
May 6, 2014 at 8:02 PM
Hi Brent,

thx. What do you think about my metioned suggestions for a hook allowing to user other response_modes (see below)? Do you think [1] oder [2] would be ok for you?

Wishes,
Manfred

Here are the suggestions ...

8<-------------------------------------

[1]
protected override async Task<AuthenticationTicket> AuthenticateCoreAsync()
{
[...]

        OpenIdConnectMessage openIdConnectMessage = null;

        if (string.Equals(Request.Method, "POST", StringComparison.OrdinalIgnoreCase)
          && [...])
        {
           [...] // Read openIdConnectMessage from Payload
        }
        // --- Start: Modifications ---
        else {
            var context = ... some context with openIdConnectMessage and current request-object ...
            Options.Notifications.NoMessageFound(context)
            openIdConnectMessage = context.Message;
        }
        // --- End: Modifications ---            

        if (openIdConnectMessage == null)
        {
            return null;
        }

[...]
}

8<-------------------------------------

[2]
protected override async Task<AuthenticationTicket> AuthenticateCoreAsync()
{
[...]

        OpenIdConnectMessage openIdConnectMessage = null;

    // --- Start: Modifications ---
        if (Options.Notifications.ReadMessage != null) {
            var context = ... some context with openIdConnectMessage and current request-object ...
            Options.Notifications.NoMessageFound(context)
            openIdConnectMessage = context.Message;

        }
        else /* --- End: Modification -- */ if (string.Equals(Request.Method, "POST", StringComparison.OrdinalIgnoreCase)
          && [...])
        {
           [...] // Read openIdConnectMessage from Payload
        }

        if (openIdConnectMessage == null)
        {
            return null;
        }

[...]
}
May 6, 2014 at 8:04 PM
Btw: Did you manage to have a look at my 2nd pull-request?
https://katanaproject.codeplex.com/SourceControl/network/forks/manfredsteyer/Issue248Alternative/contribution/6651

Wishes,
Manfred