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

custom OAuth Provider

Nov 27, 2013 at 3:39 PM
Can someone point me in the right direction? I'm looking to implement a custom OAuth provider. We would like to use the OAuth API that exposes. At the same time I would like the provider to conform to the owin specs and best practices. I haven't seen much on extending owin for custom providers. Please advise.

I was starting to dig thru the Katana project to figure it out, but figured I would ask first to make sure I implement it in the expected way.

Thanks in advance.
Nov 27, 2013 at 3:53 PM
Look at Microsoft.Owin.Security.* There are several custom OAuth providers implemented for various services.
Dec 13, 2013 at 11:07 AM
Edited Dec 13, 2013 at 11:09 AM
Now that a few OAuth2 providers have been written, I realize that we have all ended up copying existing code (not very DRY...), which leads me to think that we could refactor them to share a common base and thus no longer be limited to a defined set of providers.

Specific behaviors - endpoint address alteration or user info retrieval (which are probably the 2 main particularities of the OAuth2 providers I've seen so far) - could be supported via extension points, either via Func properties or virtual methods... or both.
Dec 13, 2013 at 5:27 PM
Such re-factoring has been proposed, but no one has really attempted it yet. The obnoxious part is that each of the providers have different flavors of OAuth, so it's not clear how much commonality we could reach. I'd love to see a mock-up if you do one.
Dec 14, 2013 at 4:15 PM
Edited Dec 31, 2013 at 2:54 PM
Your wish is my command:

Please note that it's a first version, which still lacks comments and specific unit tests, although existing ones all pass.
At this moment, only Facebook and Google middlewares inherit from the new OAuthAuthenticationClientMiddleware, but of course, the goal is to adapt the other ones.
While I've tried to avoid any breaking change, I've deliberately made changes that could seem to be against the "spirit" of existing code, and especially in IOAuthAuthenticationProvider and its implementations, where I've chosen to use typed tasks instead of specific methods in context parameters : in my opinion, this makes the flow easier to understand as we instantaneously see what should be returned to the caller.

I haven't tested using a custom OAuth2 authorization endpoint neither, but if someone wants to build a little test project, that would be cool! ;)
Dec 17, 2013 at 11:09 PM
I have tested the new OAuthAuthenticationClientMiddleware and it works well with OAuthAuthorizationServerMiddleware out-the-box, without any need to write a custom IOAuthAuthenticationProvider. Of course, you can customize its behavior through the func properties of OAuthAuthenticationProvider.
Dec 29, 2013 at 9:14 PM
Any progress?
Dec 30, 2013 at 5:06 PM
No, everyone's out for the holiday break. They'll be coming back later this week.
Jan 8, 2014 at 5:34 PM
It looks like they're not ready to tackle this unification project right now. I suggest disregarding your original breaking-change restriction, make it awesome, and then submit the result to owin-contrib.
Jan 8, 2014 at 8:27 PM
That's understandable (I imagine that the tricks included in the specific providers to avoid breaking changes have clearly led to this refusal), but particularly sad, as there's still no generic OAuth2 client included in OWIN/Katana. That said, I wonder if it could be added to Katana without adapting the other providers to use it: Facebook and Google providers would not be modified and a generic provider could be used to support any standard-compliant OAuth2 authorization server, and especially OAuthAuthorizationServerMiddleware (am I the only one finding funny that there's currently no client support while Katana offers a great server support? :P).

I've found a bunch of "owin-contrib" repositories, but I imagine that you're talking about this one:
Jan 8, 2014 at 8:41 PM
Hmm, ping and ask him where. He's organizing these.