Port the OAuth middleware from Katana

[Tratcher]

Do not port the OAuth authorization server, @blowdart says we should use the Thinktexture server instead.

[kevinchalet]

Identity Server 3 (made with love by guys from Thinktecture, not Thinktexture 😄) is a great product... but you can't compare it with the OAuth2 authorization server middleware shipped with Katana.

While OAuthAuthorizationServerMiddleware offers a fantastic vanilla/low-level OAuth2 experience that requires the end developer to implement his own application logic to complete the built-in support (e.g client redirect URI/credentials validation via IOAuthAuthorizationServerProvider or authorization form handling), IdSrv3 has a higher-level approach that comes with tons of default services: models, repositories, services and even HTML pages.

The downside of this approach is that IdSrv3 is less customizable and rather feels like an autonomous identity server than an opt-in middleware you can add in your pipeline and fully integrate in your existing application. Using IdSrv3, you can't, for instance, rely on ASP.NET MVC or Nancy to render the authorization/consent form. With OAuthAuthorizationServerMiddleware, delegating the rendering to another middleware in the pipeline is just a formality (it's even enabled by default).

Even if I'd love to see OAuthAuthorizationServerMiddleware in vNext, I imagine that this modest message won't suffice to save it from this horrible death 😄

On a side note, I started working with @manfredsteyer on an OWIN/Katana OpenID connect server directly based on OAuthAuthorizationServerMiddleware and which offers the same lovely low-level approach: https://github.com/AspNet-OpenIdConnect-Server/Owin.Security.OpenIdConnect.Server
You might consider contributing to its vNext port rather than porting OAuthAuthorizationServerMiddleware.

[manfredsteyer]

I would consider not porting OAuthAuthorizationServerMiddleware as a huge affront to all asp.net-devs, cause it has been introduced just some months ago. Makeing it legacy after that short period would really harm the confidence, all asp.net-devs have in the asp.net-team.

[manfredsteyer]

+1 for PinpointTownes: It's a product and not a middleware.

[leastprivilege]

It is not a product - it is an open source project. It is also middleware - just at an higher abstraction level.

[kevinchalet]

@leastprivilege AFAIK, we never pretended it was not an open source project nor a middleware. And we never said that IdSrv was an awful commercial product aiming at promoting your company either.

We're just saying that IdSrv is a high-level/turnkey solution - that you can integrate with the other products you're offering and thus be part of a broader ecosystem BTW - that cannot be compared with the low-level OAuthAuthorizationServerMiddleware we're using and trying to save.

[leastprivilege]

Well - then search for the word "product" and "not a middleware" on this page ;) But good - then we agree.

We respect your work - and expect the same from you. I am sure that's the case.

[kevinchalet]

"product" doesn't necessarily mean "commercial" 😄
Concerning Manfred, I'm sure he meant that IdSrv was not "just a middleware".

Don't worry, we respect your work. I'm even the first one saying on #owin that IdSrv is a great product.

[Suchiman]

I would also like to see the OAuthAuthorizationServerMiddleware ported to vNext, since it's very powerful while abstracting away the details of the OAuth protocol. Since it does not bring much ballast it's also easily integrateable. I just finished building my companies central authorization provider based on the OAuthAuthorizationServerMiddleware, it would be pitty to see it only lasting a single version and also hurt my confidence on how future prove my investions in code relying on relatively newly introduced default components are.

+1 for PinpointTownes

[ycrumeyrolle]

OAuthAuthorizationServerMiddleware is a good starting point.
IdSrv3 is a great implementation, but has some caveats (for example dependencies on some external packages).
It would be great that IdSrv3 (or IdSrv3.1) were based on OAuthAuthorizationServerMiddleware,
And if Katana team wants to abandon this middleware, IdSrv3 could perhaps merge it into its core ?

[leastprivilege]

Which external dependencies are you talking about?

https://github.com/thinktecture/Thinktecture.IdentityServer.v3.Samples/blob/master/source/SelfHost%20(Minimal)/SelfHost/packages.config

...and Microsoft actually asked us to test drive the OAuth2 AS middleware before they released it. It was limited in its functionality and no further development was planned. That's why we decided to start IdSrv3.

[kevinchalet]

@leastprivilege ah ah, ILMerge FTW! 😄 (https://github.com/thinktecture/Thinktecture.IdentityServer.v3/blob/master/source/Core/packages.config)

@ycrumeyrolle IMHO, having dependencies on multiple projects is not really an issue. The main problem I have with IdSrv3 is that it relies on Web API, which limits the way you can integrate IdSrv3 in an OWIN/Katana pipeline.

[ycrumeyrolle]

My main concern is Autofac and Thinktecture.IdentityModel.

I am not confortable to use two differents IoC framework. So if I use IdSrv3, I am feeling forced to use it for any extension.

And for Thinktecture.IdentityModel, even if it is the prefered default implementation, it should be possible to switch to another.(maybe it is already possible?)

The OAuth middleware seems to give an higher level of abstraction, but I see that IdSrv3 is still evolving.

[brockallen]

@ycrumeyrolle -- when you use IdentityServer you are not using Autofac or WebAPI. Those libraries are an implementation detail.

[Tratcher]

Side note about packaging. We used MS.A.Sec.OAuth for the base OAuth2 middleware. Do we put the OAuth bearer token middleware in there as well, or in a separate package? The only reason to separate them would be that the new package has a Newtonsoft.Json dependency. The old package didn't, but it was almost always used together with the JWT package which pulled in Newtonsoft.Json anyways.

[leastprivilege]

If you want to keep the AS middleware - I would put it into a separate package so it can have a life of its own.

[davidpeden3]

Cross referencing posts: http://katanaproject.codeplex.com/workitem/209

A small handful of us have implemented our own JwtFormat.Protect to get what should have been out-of-the-box support for JWTs in the OAuth2 middleware. I am definitely keeping my eye on IdSrv v3 (currently slated to release at the end of the year: Milestones) and will seriously consider switching once it's RTM.

Having said that, as many have pointed out, they really are apples to oranges. I don't see how multiple options are a bad thing.

[tymarats]

+1 for keeping OAuthAuthorizationServerMiddleware. As many have pointed out, even though Thinktecture.AuthorizationServer is a great project (from both academical and usability point of view), it's much more than just a middleware and not something that's necessarily needed by everyone. Having a low-level easy-to-configure server can be very useful and I don't really see the need for its termination.

[manfredsteyer]

Just for the record: IdSvr is a great product and dominick is one of the best guys in the area of security. In Addition to that, the SelfHost-(minimal)-sample seems to be really cool and lightweight. But, as mentioned, I do believe that not porting the existing middleware-components would really be a bad decision.

[Tratcher]

The Bearer token middleware has been ported. I recommend opening a separate bug specific to the OAuth server discussion.

[Xacron]

For anyone still looking for the original OAuth Authorization Server in ASP.NET 5, I have ported the code and the original sample here:
https://github.com/XacronDevelopment/oauth-aspnet

The port includes backwards compatibility to allow ASP.NET 4.x resource servers to read the access tokens created by the authorization server.

The nuget packages are here:
https://www.nuget.org/packages/OAuth.AspNet.AuthServer
https://www.nuget.org/packages/OAuth.AspNet.Tokens
https://www.nuget.org/packages/OAuth.Owin.Tokens