Are there any better alternatives to DotNetOpenAuth? [closed]

Question

I am really really trying to like DotNetOpenAuth, an OpenId, OAuth library for .Net, but it really doesn't cut it for me.
First of all it doesn't seem to work on mono (the examples fail with web.config error or other errors).
Secondly, I don't need 99% of the features of the library, all I want is something simple that takes care of OpenId/OAuth client usage complexity for me. I don't need to write an OpenId server—I just want my users to click on a "login with Google" button :-)

All that I want to do is have a set of buttons for having users login on my web site with (any one is nice, all three bonus):

• Facebook (does not support OAuth, so it's unlikely)
• Twitter
• Google

Are there any simple, usable alternatives that give me something like:

1. A drop in snippet or component to put in pages
2. Ideally it would simply set HttpContext.Current.User
3. Integration with Membership—Basically using membership to track who was on the site before.

?

Glassco

I am doubting you will find a "simple" answer to this, as regardless of what you end up with, it will be a wrapper over a fairly complex API. A word of warning: Facebook does not support OpenId, so any solution that supports the three providers you listed above will not be trivial. – Discontinue

Did you try the mono branch of DNOA: github.com/AArnott/dotnetopenid/tree/mono2 – Pennsylvanian

@szt Unfortunately it doesn't even compile, because in fact it has windows-specific deps... :-( – Glassco

@Skilwz: Sorry, my bad. A year ago I patched the actual branch, and used it in a few projects: github.com/sztupy/dotnetopenid But it's a really old branch... – Pennsylvanian

As a side note for anyone reading this and considering Open ID, it appears that at least Google has deprecated it. The writing is on the wall to use Open ID Connect, which confusingly, is built on top of OAuth2 and not on top of Open ID. – Stanfill

Answer 1

(self-admitted bias alert: author of DotNetOpenAuth)

DotNetOpenAuth has a couple of mono branches that can work, and have worked in the past. You may find that they don't build under mono in Linux, but those branches when built in Windows produce a dotnetopenauth.dll that should be able to run under Linux. But it's been a while since I've done it myself so I can't help you much.

Mono hasn't shown much desire to fix the bugs and fill the feature holes that DotNetOpenAuth runs into when ported to mono, so these mono branches are quite old.

I wanted to call out that your "all I need is a simple client, not the provider" comment seems dangerously ill-informed. No OpenID or OAuth 1.0 client is simple. Getting it right, and secure, is actually a very big job. In addition, once you have the client side (RP) fully supported and secure, adding the server-side (Provider) is actually is actually only a very small addition since RP and OP can share so much code.

So yes, DotNetOpenAuth supports more scenarios than you need. But don't most libraries? Please take a look at An argument for the extra dependency of a library.

And drop a note to the mono developers asking them to fix the bugs and fill the feature holes in mono so that DotNetOpenAuth runs better on it. I've asked them repeatedly, but I guess they need to hear more devs ask for it.

Solberg

I think you should take the criticism in stride. There are exactly zero basic examples. Everything uses oauth lingo. The library needs to implement workarounds for mono. Take it home and improve the library :-) besides that, this is notban answer to my question... ;-) – Glassco

I haven't taken offense at your criticism. But StackOverflow isn't a forum for criticism anyway, and your question is halfway down, after a lot of your rants that probably could be addresses by emailing the mailing list or filing issues on the project's web site. I find it amusing that you're telling me to take it home and improve it, when this is an open source project that you can improve yourself, and yet you haven't donated anything (AFAIK) yourself. Stop complaining and help yourself. I don't have or need mono support, so someone who does (you!) should "take it home and improve [it]". – Solberg

as you see fit, I have no need of DNOA either... And tbh the whole appeal of such a library is out-of-the-box support, missing that... not really. – Glassco

@AndrewArnott: Where can we find the Mono forks for DotNetOpenAuth? Maybe some of them could be used in .NET Core.. – Infantile

Answer 2

I'm finding myself in this same situation. The OAuth libraries for other platforms (e.g. Python) are far simpler and more elegant, and seem to encapsulate much of the complexity in OAuth, so that from the client's perspective it's just a few lines of code (which is the mark of a well designed library, IMHO).

I finally settled on Hammock - a library which assists in consuming restful APIs, including OAuth 1.0A support.

Calces

Answer 3

Identity Server (IdSrv)

OpenID Connect and OAuth 2.0 Framework for ASP.NET Core

Source: https://github.com/IdentityServer

Watch this introduction video https://vimeo.com/154172925

Microsoft AspNet.Security.OpenIdConnect.Server (ASOS)

AspNet.Security.OpenIdConnect.Server is an advanced OAuth2/OpenID Connect server framework for both ASP.NET Core 1.0 (previously known as ASP.NET 5) and OWIN/Katana, designed to offer a low-level, protocol-first approach.

Source: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server

OpenIddict

OpenIddict aims at providing a simple and easy-to-use solution to implement an OpenID Connect server in any ASP.NET Core application.

Source: https://github.com/openiddict/openiddict-core

Haden

Answer 4

A year ago I patched the actual mono2 branch of DNOA. It's really old, but it works (only tryied the OpenID part though), and I still use it for a few projects. Didn't knew the current mono2 branch is still unusable :(

https://github.com/sztupy/dotnetopenid

Pennsylvanian

Answer 5

When developing my own provider, I tried about 5 different libraries before settling on DotNetOpenAuth and it really gave the best results. One problem with OpenID is that RPs and IPs sometimes have a fair bit of difficulty communicating due to how varied the implementations can be. My first attempt with a different library resulted in OpenIDs that worked only on about 50% of the sites I tested it on. DotNetOpenAuth worked on about 90%. I would expect similar performance parallels when testing this from the Relying Party side. One alternative you could look into though is Janrain's RPX, which is also high quality.

Macrospore

Answer 6

Not exactly an alternative to DotNetOpenAuth,though I believe it might be helpful for you. To solve similar problem - I needed only simple login OpenID screen - I found openid-selector. They have several very simple examples (jQuery,MooTools and prototype libraries can be used) how to setup login page similar to stack overflow's.

Sagunto