I plan to develop a web application that supports OpenID Connect as a relying party, so that a user of the application can sign up and log in using the identity provider of his choice. (This is the same tech that "My Logins" on each Stack Exchange site uses.) This application would be available for download and installation by server operators, much as WordPress, phpBB, and MediaWiki software are made available. With which OpenID Connect providers should a server operator expect to have to sign up manually?
Back when OpenID 2.0 was the most common protocol version, most identity providers (IDPs) allowed any relying party (RP) to use their identity services. Only a few IDPs operated a whitelist of RPs; the one I ran into was PayPal Access (now called Log In with PayPal). There are business reasons to close access, but a closed policy required extra effort for IDPs, so most didn't bother.
In April 2015, Google dropped OpenID 2.0 in favor of OpenID Connect, in which each RP is an OAuth 2.0 client application with its own client ID and client secret issued by the provider. Normally, OAuth requires each client to register with each provider out of band, which is fine when each provider exposes a protected resource with a unique API. But OpenID Connect is a common authentication API that all IDPs are expected to expose the same way when the user enters a corresponding OpenID identifier URI into a RP's login page. So the OpenID Connect spec describes an optional Dynamic Client Registration (dyn-reg) feature that allows an RP to automatically register as an OAuth client, as mentioned in Hans Z.'s answer to "Can you use OpenID Connect without obtaining OAuth credentials?". However, each IDP has to make the effort to implement dyn-reg. Google and PayPal are examples of OpenID Connect IDPs that have chosen not to do so. And even if a provider does implement dyn-reg, the spec still allows the IDP to require that the RP first present a valid Initial Access Token issued by the provider. Thus if there are n RPs and m public IDPs, a human has to read and accept a contract n*m times.
To put it another way, the default in OpenID 2.0 is open; the default in OpenID Connect is closed.
So as more OpenID providers follow Google's lead and drop OpenID 2.0 in favor of OpenID Connect, if I take an RP live, I expect end users who paste in an identifier URI to be turned away with an error message to the effect "The provider of this identifier is unknown to Example.com and does not support Dynamic Client Registration." The operator of a server running my web application would then have to read the log of such errors and manually sign up with each such IDP to obtain client credentials. And I would have to build configuration variables into this web application to let the server operator specify client credentials for each popular provider in advance, so that the site's users are converted instead of disappointed.
I want to make it easy for a server operator who has downloaded my application to install it on a web server in his domain and go live as an RP. So I want its setup process to suggest public IDPs for which server operators are likely to run into this problem, as opposed to just a blank "Add OpenID Connect Provider" form that leaves the administrator on his own.
Other related questions (OpenID Connect providers and List of OpenID Connect providers) have a list that is too short, out of date, not separating IDPs for which manual registration is expected, and not separating popular IDPs from niche ones. For example, Salesforce.com is a niche IDP that allows only its own customers to be RPs, and I don't think end users will expect to be able to enter an identifier from a niche IDP on a public web application. I'd like to know from what sources I could gather information about widely used IDPs myself and keep up to date.
So how would I go about finding well-known general-purpose OpenID Connect providers that don't support open Dynamic Client Registration before taking a site live?
- Best location to check for OpenID connect providers is here: http://openid.net/developers/libraries/ and up-to-date list of certified providers is here: http://openid.net/certification/
2. If I understood correctly, your use case is totally supported by OpenID Connect. 3. I recommend that you take look at IdentityServer3: https://github.com/IdentityServer/IdentityServer3 , as I am sure it will answer your requirements. I am using it personally and its great open source project maintained and developed by experts in the security domain.
I am not sure if you really require Dynamic Client Registration, in OIDC your whole application considered as single client/RP. your application clients/users (and set of users per each client of your application) is totally supported by most OIDC providers without requiring Dynamic Client Registration. you would need DCR if your application is umbrella of dynamic portals.