OpenID, how to develop a provider

Question

Currently I'm developing some infrastructure and I've implemented my own RESTful authentication mechanism.

Now I've in mind that maybe I shouldn't go this way and use an industry standard so interoperability with my project could be trivial and easier to understand in terms of authentication and authorization.

After checking some articles googling everywhere and reading some Q&A here in Stackoverflow, I don't find how to be an OpenID provider - I'm not talking about authenticate users using Google, Windows Live, Facebook Connect and so, I want to develop an OpenID-enabled system so if some want to register into my services, they'll do in my own domain -.

Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?

Thank you.

Duntson

I would argue the "industry standard" is using existing OID providers, not rolling your own. I'm not sure what the benefit of that would be. – Westbrooks

@MattGrande This is the part I'm not understanding. Is an standard if some private companies hold user data, but no one can become an OpenID provider if you aren't a big company? – Honorable

Absolutely anyone can become an OpenID provider, it is not just for big companies. – Hwahwan

@Hwahwan Will you elaborate this in an answer, please? I'd like to know how, and which are the recommended resources (.NET libraries) to use in order to accomplish this :) – Honorable

I'm saying that the benefit of OID is that you don't need another login. Users will be able to go to other websites and login using their existing credentials. This is only benefitial if there's a pretty good chance that people already have an account with your service. So, unless you're playing with the big boys (Google, Microsoft, Facebook, etc), I guess I don't really see the point. – Westbrooks

@MattGrande You're right, but don't think in OpenID for getting authenticated everywhere, in any service in the world. Just imagine you want to create some cloud services and you don't want to force everyone to re-register in any of them. Ok, this "Matias OpenID" won't be interesting for logging-in in Stackoverflow, but it should be interesting for logging-in in my X,Y,Z,N services. Instead of creating my own "single sign-on" system, I'd prefer to use a common standard, so my products will be easier to understand and interoperate. – Honorable

Gotcha. I was reading this as "I have one website, now I'm going to roll my own OID." I guess I can see it being useful if you have several cloud services. (I can't help you out though, sorry!) – Westbrooks

Answer 1

Developing an OpenID Provider as a means of Single-Sign-On (SSO) within an organizations ring of web sites is a very valid scenario. DotNetOpenAuth comes with a pair of sample web sites (a Provider and a Relying Party) that demonstrate a single-sign-on relationship. They're called OpenIdWebRingSsoProvider and OpenIdWebRingSsoRelyingParty.

Please do not attempt to implement OpenID by yourself any more than you'd implement SSL by yourself. Getting OpenID security and interoperability just right takes a very long time and a deep level of domain knowledge. DotNetOpenAuth in particular gives you programmatic access to do just about anything you'd want to with OpenID, and since it's free, it's hard to go wrong.

Disclosure: I am a developer behind DotNetOpenAuth.

Vegetarian

+1 Really I never wanted to implement OpenID from scratch, I hate reinventing wheels if there's one that's enough for my own needs, it's all about good programming practices. By the way, can you instruct me if I can integrate DotNetOpenAuth in my own infrastructure? Using DotNetOpenAuth, is it possible to create an OpenID provider and login thought it, but without user interaction? I mean, if I integrate OpenID in my IoC container, can I pass credentials programatically and get logged-in the same way as an interactive login? Thanks! – Honorable

DotNetOpenAuth itself presents no UI at all for Providers - that's up to your web site. DNOA merely implements the protocol. So yes, it sounds like it will work for you. – Vegetarian

Yes, I've been looking at the class library and so, and I found that. Thank you very much for your useful info! – Honorable

In addition, I've marked your question as the right one, because I believe it answers accurately my concerns. – Honorable

@AndrewArnott I noticed that your repo at github.com/DotNetOpenAuth/DotNetOpenAuth has been marked "archived" since 2019. Do you have any suggestions for a currently-maintained successor library? This question and your answer and library are almost exactly what we were looking for. We need to integrate with a provider that supports OIDC but also expects all our users to already have an IdP. The problem is that our system is 22 years old and uses its own credential store designed pre-OIDC. Oh, and we also support only .NET Framework 4.8.1. (i.e. no .NET Core/5+). – Suspender

I'm afraid I haven't kept up in the OpenID space at all since that repo was archived. Best of luck. – Vegetarian

Answer 2

Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?

1. How to become an OpenID Provider
2. DotNetOpenAuth has some hiccups but all-in-all is a good tool to use it under .NET

if you're think you can do it, you can follow this:

Lastly, and most challenging, is implementing custom support for OpenID in your software and account management tools. While this approach of course affords the greatest degree of control over the user experience, it is also the most risky and only for developers experienced with web security. Start by reviewing the specs and documentation.

---

But my question would always be:

Why one more provider? Facebook, Google, MyOpenID, ... already have it, and with them, plenty of users have (even without them knowing) an OpenID login...

StackExchange is an OpenID provider since a while ago, but... there's so much users cross StackExchange platform. Are you developing such a big community so it will be reasonable to create and implement your own provider?

Achaean

Hey, thanks for this text, I really appreciate it. About (1) Why one more provider? or (2) Are you developing such a big community?. (1) I don't want to be a provider for the masses, I want to develop an authentication and authorization based on open standards, that's all. And, because of my requirements, I need a single sign-on solution (why not OpenID?) then?). (2) It won't be a big community, but a developer-oriented product in the cloud which is going to have more than a service and even an official support site (continues in the next comment) – Honorable

(continuation) so I believe a single sign-on solution would be the best one. And again, instead of relying on my own way of authenticating and authorizing others, why not OpenID? :D – Honorable

Anyway, and after all, I see implementing your own OpenID server is a big business itself and maybe you're right about why one more, because a cloud product should start relying on other cloud products. This is cloud computing, isn't it? – Honorable

Well, I marked this as the right one because it's, more or less, a good start to learn how to create an OpenID provider. Finally, since I've a lot of things to do before opening my authentication with OpenID, I'm going to go forward with my own RESTful/HTTP authentication mechanism and, if project has a great success, I'll be able to do that great effort. Thank you ;) – Honorable

Answer 3

I see the answers are couple of years old. If you are looking for the latest solution to build an OpenID provider using Microsoft technology stack, IdentityServer is the open source option. One can use this and build an Open ID connect Identity provider.

Documentation on how to use and build : https://identityserver4.readthedocs.io/en/latest/

IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.

It enables the following features in your applications:

Authentication as a Service Centralized login logic and workflow for all of your applications (web, native, mobile, services). IdentityServer is an officially certified implementation of OpenID Connect.

Single Sign-on / Sign-out Single sign-on (and out) over multiple application types.

Access Control for APIs Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps.

Federation Gateway Support for external identity providers like Azure Active Directory, Google, Facebook etc. This shields your applications from the details of how to connect to these external providers.

Focus on Customization The most important part - many aspects of IdentityServer can be customized to fit your needs. Since IdentityServer is a framework and not a boxed product or a SaaS, you can write code to adapt the system the way it makes sense for your scenarios.

Mature Open Source IdentityServer uses the permissive Apache 2 license that allows building commercial products on top of it. It is also part of the .NET Foundation which provides governance and legal backing.

Curlew

Identity Server is switching to a commercial model and the open source version will receive its last update in Nov. 2022... – Carolecarolee