Ich plane, eine Webanwendung zu entwickeln, die OpenID Connect als vertrauende Partei unterstützt, damit sich ein Benutzer der Anwendung mit dem Identitätsanbieter seiner Wahl anmelden und anmelden kann. (Dies ist dieselbe Technologie, die "Meine Anmeldungen" auf jeder Stack Exchange-Site verwendet.) Diese Anwendung kann von Serverbetreibern heruntergeladen und installiert werden, sofern WordPress-, phpBB- und MediaWiki-Software verfügbar sind. Mit welchen OpenID Connect-Anbietern muss sich ein Server-Betreiber voraussichtlich manuell anmelden?

Zurück, als OpenID 2.0 die am häufigsten verwendete Protokollversion war, erlaubten die meisten Identitätsanbieter (IDPs) allen vertrauenden Parteien (RPs), ihre Identitätsdienste zu nutzen. Nur wenige Binnenvertriebene führten eine Whitelist mit RPs. Das, auf das ich gestoßen bin, war PayPal Access (jetzt mit dem NamenMelden Sie sich mit PayPal an). Es gibt geschäftliche Gründe, den Zugriff zu sperren, aber eine Sperrung der Richtlinie erforderte zusätzliche Anstrengungen für Vertriebene, sodass sich die meisten nicht darum kümmerte

Im April 2015 hat Google OpenID 2.0 zugunsten von OpenID Connect gelöscht. Dabei handelt es sich bei jedem RP um eine OAuth 2.0-Clientanwendung mit einer eigenen Client-ID und einem vom Anbieter herausgegebenen Client-Geheimnis. Normalerweise erfordert OAuth, dass sich jeder Client bei jedem Anbieter außerhalb des Bandes registriert. Dies ist in Ordnung, wenn jeder Anbieter eine geschützte Ressource mit einer eindeutigen API verfügbar macht. OpenID Connect ist jedoch eine gemeinsame Authentifizierungs-API, die von allen IDPs auf dieselbe Weise erwartet wird, wenn der Benutzer einen entsprechenden OpenID-ID-URI in die Anmeldeseite eines RP eingibt. Also dasOpenID Connect spec beschreibt eine optionale Dynamische Client-Registrierung (dyn-reg), die es einem RP ermöglicht, sich automatisch als OAuth-Client zu registrieren, wie in @ erwähnntwort von Hans Z. auf "Können Sie OpenID Connect verwenden, ohne OAuth-Anmeldeinformationen zu erhalten?". Jeder IDP muss sich jedoch die Mühe machen, dyn-reg zu implementieren. Google und PayPal sind Beispiele für OpenID Connect-IDPs, die sich dagegen entschieden haben. Und selbst wenn ein Provider Dyn-reg implementiert, kann der IDP nach der Spezifikation verlangen, dass der RP zuerst ein gültiges Initial Access Token vorlegt, das vom Provider ausgestellt wurde. Also, wenn esn RPs undm öffentliche Binnenvertriebene, ein Mensch muss einen Vertrag lesen und akzeptierenn*m mal.

Um es anders auszudrücken, ist der Standard in OpenID 2.0 offen; Der Standard in OpenID Connect ist geschlossen.

So folgen mehr OpenID-Anbieter Googles Führung und lassen OpenID 2.0 zugunsten von OpenID Connect fallen. Wenn ich ein RP live nehme, erwarte ich, dass Endbenutzer, die einen Bezeichner-URI einfügen, mit einer Fehlermeldung abgewiesen werden, die den Effekt "Der Anbieter" hat dieses Bezeichners ist Example.com nicht bekannt und unterstützt die dynamische Client-Registrierung nicht. " Der Betreiber eines Servers, auf dem meine Webanwendung ausgeführt wird, muss dann das Protokoll solcher Fehler lesen und sich bei jedem dieser IDPs manuell anmelden, um Client-Anmeldeinformationen zu erhalten. Außerdem müsste ich Konfigurationsvariablen in diese Webanwendung einbauen, damit der Server-Betreiber die Client-Anmeldeinformationen für jeden gängigen Anbieter im Voraus festlegen kann, damit die Benutzer der Site konvertiert werden, anstatt enttäuscht zu werden.

Ich möchte es einem Server-Betreiber, der meine Anwendung heruntergeladen hat, leicht machen, sie auf einem Webserver in seiner Domäne zu installieren und als RP live zu schalten. Daher möchte ich, dass der Einrichtungsprozess öffentliche IDPs vorschlägt, bei denen Serveroperatoren wahrscheinlich auf dieses Problem stoßen, und nicht nur ein leeres Formular zum Hinzufügen eines OpenID Connect-Anbieters, bei dem der Administrator allein bleibt.

Weitere Fragen OpenID Connect-Anbieter undListe der OpenID Connect-Anbieter) haben eine zu kurze, veraltete Liste, in der keine IDPs, für die eine manuelle Registrierung erwartet wird, und keine beliebten IDPs von Nischen-IDPs getrennt werden. Beispielsweise ist Salesforce.com ein Nischen-IDP, dererlaubt nur seinen eigenen Kunden, RPs zu sein, und ich glaube nicht, dass Endbenutzer erwarten, in einer öffentlichen Webanwendung eine Kennung aus einem Nischen-IDP eingeben zu können. Ich möchte wissen, aus welchen Quellen ich selbst Informationen über weit verbreitete Binnenvertriebene sammeln und auf dem Laufenden halten kann.

Wie kann ich bekannte OpenID Connect-Universalanbieter finden, die die Open Dynamic Client-Registrierung nicht unterstützen?Vo eine Seite live nehmen?