Frage Was ist der Unterschied zwischen OpenID und OAuth?


Ich versuche wirklich den Unterschied zwischen OpenID und OAuth zu verstehen? Vielleicht sind das zwei völlig getrennte Dinge?


813
2017-07-06 13:40


Ursprung


Antworten:


OpenID geht es um Authentifizierung (dh zu beweisen, wer du bist), OAuth handelt von Autorisierung (dh um Zugriff auf Funktionalität / Daten / etc .. zu gewähren, ohne mit der ursprünglichen Authentifizierung umgehen zu müssen).

OAuth kann in externen Partnerstandorten verwendet werden, um den Zugriff auf geschützte Daten zu ermöglichen, ohne dass ein Benutzer erneut authentifiziert werden muss.

Der Blogpost "OpenID versus OAuth aus der Sicht des Benutzers"hat einen einfachen Vergleich der beiden aus der Sicht des Benutzers und"OAuth-OpenID: Sie bellen den falschen Baum auf, wenn Sie denken, dass es sich um die gleiche Sache handelt"hat mehr Informationen darüber.


702
2017-07-06 13:47



Es gibt drei Möglichkeiten, OAuth und OpenID zu vergleichen:

1. Zwecke

OpenID wurde für die föderierte Authentifizierung erstellt, dh Sie lassen Ihre Benutzer von einem Drittanbieter authentifizieren, indem Sie bereits vorhandene Konten verwenden. Der Begriff "föderiert" ist hier von entscheidender Bedeutung, weil der ganze Sinn von OpenID darin besteht, dass jeder Provider verwendet werden kann (mit Ausnahme von White-Listen). Sie müssen nicht vorab eine Vereinbarung mit den Anbietern treffen oder diese aushandeln, um den Nutzern die Nutzung eines anderen Kontos zu ermöglichen.

OAuth wurde erstellt, damit Benutzer ihre Kennwörter nicht mehr mit Anwendungen von Drittanbietern teilen müssen. Es begann tatsächlich als eine Möglichkeit, ein OpenID-Problem zu lösen: Wenn Sie OpenID auf Ihrer Site unterstützen, können Sie keine HTTP-Basisanmeldeinformationen (Benutzername und Kennwort) verwenden, um eine API bereitzustellen, da die Benutzer kein Kennwort auf Ihrer Site haben.

Das Problem bei dieser Trennung von OpenID zur Authentifizierung und OAuth zur Autorisierung besteht darin, dass beide Protokolle viele der gleichen Dinge erreichen können. Sie stellen jeweils einen anderen Satz von Merkmalen bereit, die von verschiedenen Implementierungen gewünscht werden, aber im Wesentlichen sind sie ziemlich austauschbar. Im Kern sind beide Protokolle eine Assertion-Verifikationsmethode (OpenID ist auf die Behauptung "Dies ist, wer ich bin" beschränkt, während OAuth ein "Zugriffstoken" bereitstellt, das über eine API für jede unterstützte Assertion ausgetauscht werden kann).

2. Funktionen

Beide Protokolle bieten eine Möglichkeit für eine Site, einen Benutzer woanders umzuleiten und mit einer überprüfbaren Assertion zurückzukommen. OpenID bietet eine Identitätszusicherung, während OAuth allgemeiner in Form eines Zugriffstokens ist, das dann verwendet werden kann, um "Fragen an den OAuth-Provider zu stellen".. Sie unterstützen jedoch jeweils unterschiedliche Merkmale:

OpenID - Das wichtigste Merkmal von OpenID ist sein Entdeckungsprozess. OpenID erfordert keine harte Codierung jeder der Anbieter, die Sie im Voraus verwenden möchten. Mithilfe der Erkennung kann der Benutzer einen beliebigen Drittanbieter auswählen, der authentifiziert werden soll. Dieses Erkennungsmerkmal hat auch die meisten Probleme von OpenID verursacht, da die Art und Weise, wie es implementiert wird, darin besteht, HTTP-URIs als Kennungen zu verwenden, die die meisten Web-Benutzer nicht bekommen. Weitere Funktionen von OpenID sind die Ad-hoc-Client-Registrierung mit DH-Austausch, der Sofort-Modus für optimierte Endbenutzererfahrung und die Möglichkeit, Assertionen zu verifizieren, ohne einen weiteren Hin- und Rückweg zum Provider zu machen.

OAuth- Das wichtigste Merkmal von OAuth ist das Zugriffs-Token, das eine langanhaltende Methode zum Erstellen zusätzlicher Anforderungen bietet. Im Gegensatz zu OpenID endet OAuth nicht mit der Authentifizierung, sondern bietet ein Zugriffstoken, um auf zusätzliche Ressourcen zugreifen zu können, die von demselben Drittanbieterdienst bereitgestellt werden. Da OAuth die Erkennung jedoch nicht unterstützt, müssen die Anbieter, die Sie verwenden möchten, vorab ausgewählt und hart codiert werden. Ein Nutzer, der Ihre Website besucht, kann keine IDs verwenden, die nur von Ihnen ausgewählt wurden. OAuth verfügt auch nicht über ein Identitätskonzept. Um es für die Anmeldung zu verwenden, müssen Sie also entweder einen benutzerdefinierten Parameter hinzufügen (wie bei Twitter) oder einen anderen API-Aufruf ausführen, um den aktuell angemeldeten Benutzer zu erhalten.

3. Technische Implementierungen

Die beiden Protokolle teilen eine gemeinsame Architektur bei der Verwendung der Umleitung, um Benutzerautorisierung zu erhalten. In OAuth autorisiert der Benutzer den Zugriff auf seine geschützten Ressourcen und in OpenID auf ihre Identität. Aber das ist alles, was sie teilen.

Jedes Protokoll hat eine andere Art, eine Signatur zu berechnen, die verwendet wird, um die Authentizität der Anfrage oder Antwort zu verifizieren, und jede hat unterschiedliche Registrierungsanforderungen.


319
2017-07-06 13:45



OpenID ist (hauptsächlich) für die Identifizierung / Authentifizierung, so dass stackoverflow.com weiß, dass ich besitze chris.boyle.name (oder wo auch immer) und deshalb bin ich wahrscheinlich die gleiche Person, die besaß chris.boyle.name gestern und verdiente sich einige Reputationspunkte.

OAuth ist so konzipiert, dass Sie in Ihrem Namen Maßnahmen ergreifen können stackoverflow.com (oder wo auch immer), kann die Erlaubnis zu sagen, sagen, in Ihrem Namen automatisch, ohne Ihr Twitter-Passwort zu kennen.


93
2018-05-19 08:37



Viele Leute besuchen das noch, also ist hier ein sehr einfaches Diagramm, um es zu erklären

OpenID_vs._pseudo-authentication_using_OAuth

Courtesy Wikipedia


78
2017-07-06 20:15



OAuth 

Wird für delegiert verwendet authorization Nur - das bedeutet, dass Sie einem Drittanbieter-Dienst den Zugriff auf personenbezogene Daten gestatten, ohne ein Kennwort zu vergeben. Auch OAuth- "Sitzungen" leben im Allgemeinen länger als Benutzersitzungen. Dies bedeutet, dass OAuth Autorisierung ermöglichen soll

d. h., Flickr verwendet OAuth, um es Drittanbieterdiensten zu ermöglichen, ein Personenbild in ihrem Namen zu posten und zu bearbeiten, ohne dass sie ihren Flicker-Benutzernamen und ihr Passwort ausgeben müssen.

OpenID

Gewöhnt an authenticate Single-Sign-On-Identität. Alles, was OpenID tun soll, ist, einem OpenID-Anbieter zu erlauben, zu beweisen, dass du sagst, dass du es bist. Viele Websites verwenden jedoch eine Identitätsauthentifizierung zur Autorisierung (die beiden können jedoch getrennt werden).

Das heißt, man zeigt seinen Pass am Flughafen, um den Namen der Person zu bestätigen (oder zu beweisen), deren Name auf dem Ticket ist, das sie benutzen.


39
2018-03-20 19:37



Verwenden Sie OAuth, wenn Ihre Benutzer sich nur mit Facebook oder Twitter anmelden möchten. Verwenden Sie OpenID, wenn Ihre Benutzer Neckbeards sind, die ihre eigenen OpenID-Anbieter betreiben, weil sie "nicht wollen, dass jemand anders ihre Identität besitzt".


30
2017-08-27 23:27



OpenID und OAuth sind jeweils HTTP-basierte Protokolle zur Authentifizierung und / oder Autorisierung. Beide sollen es Benutzern ermöglichen, Aktionen auszuführen, ohne Clients oder Dritten Authentifizierungs- oder Pauschalberechtigungen zu erteilen. Während sie ähnlich sind und Standards vorgeschlagen werden, um sie beide zusammen zu verwenden, sind sie separate Protokolle.

OpenID ist für die föderierte Authentifizierung vorgesehen. Ein Client akzeptiert eine Identitätsbestätigung von einem beliebigen Provider (obwohl es Clients freigestellt ist, Whitelist- oder Blacklist-Provider zu verwenden).

OAuth ist für die delegierte Autorisierung vorgesehen. Ein Client registriert sich bei einem Anbieter, der Autorisierungstoken zur Verfügung stellt, die er für Aktionen im Namen des Benutzers akzeptiert.

OAuth ist derzeit besser für die Autorisierung geeignet, da weitere Interaktionen nach der Authentifizierung in das Protokoll integriert sind, aber beide Protokolle sich entwickeln. OpenID und seine Erweiterungen können für die Autorisierung verwendet werden, und OAuth kann für die Authentifizierung verwendet werden, was als No-Op-Autorisierung angesehen werden kann.


17
2018-01-12 11:18



Ich halte es für sinnvoll, diese Frage erneut zu prüfen, wie auch in den Kommentaren darauf hingewiesen wurde, dass die Einführung von OpenID Connect möglicherweise für mehr Verwirrung gesorgt hat.

OpenID Connect ist ein Authentifizierungsprotokoll wie OpenID 1.0 / 2.0, aber es ist eigentlich auf OAuth 2.0 aufgebaut, so dass Sie Autorisierungsfunktionen zusammen mit Authentifizierungsfunktionen erhalten. Der Unterschied zwischen den beiden wird in diesem (relativ neuen, aber wichtigen) Artikel ausführlich erklärt: http://oauth.net/articles/authentication/


13
2017-10-06 06:41



Es ist mehr eine Erweiterung der Frage als eine Antwort, aber sie kann den oben genannten technischen Antworten eine Perspektive geben. Ich bin ein erfahrener Programmierer in einer Reihe von Bereichen, aber insgesamt keine Programmierung für das Web. Versuche nun eine webbasierte Anwendung mit dem Zend Framework zu erstellen.

Definitiv implementiert eine anwendungsspezifische Basis Benutzername / Passwort-Authentifizierung-Schnittstelle, aber erkennen, dass für eine wachsende Anzahl von Nutzern der Gedanke eines noch einen anderen Nutzernamen und ein Passwort ist eine Abschreckung. Obwohl nicht gerade Social Networking, weiß ich, dass ein sehr großer Prozentsatz der potenziellen Nutzer der Anwendung bereits Facebook- oder Twitter-Accounts hat. Die Anwendung möchte oder will nicht unbedingt auf Informationen über das Konto des Benutzers von diesen Websites zugreifen, sondern möchte lediglich den Komfort bieten, dass der Benutzer keine neuen Kontoanmeldeinformationen einrichten muss, wenn er dies nicht möchte. Aus der Sicht der Funktionalität scheint dies ein Aushängeschild für OpenID zu sein. Offenbar sind weder Facebook noch Twitter OpenID-Anbieter, obwohl sie die OAuth-Authentifizierung für den Zugriff auf ihre Benutzerdaten unterstützen.

In all den Artikeln, die ich über die beiden gelesen habe und wie sie sich unterscheiden, wollte ich, bis ich Karl Anderson's obige Beobachtung sah, dass "OAuth für die Authentifizierung verwendet werden kann, was man sich als eine No-Op-Autorisierung vorstellen kann" Ich sah eine ausdrückliche Bestätigung, dass OAuth für das, was ich tun wollte, gut genug war.

In der Tat, als ich diese "Antwort" posten wollte und nicht zu der Zeit Mitglied war, schaute ich lange und gründlich auf den unteren Rand dieser Seite, um mich zu identifizieren. Die Option, einen OpenID-Login zu verwenden oder einen zu erhalten, wenn ich keinen hatte, aber nichts über Twitter oder Facebook, schien darauf hinzudeuten, dass OAuth für den Job nicht geeignet war. Aber dann öffnete ich ein weiteres Fenster und suchte nach dem allgemeinen Anmeldeprozess für stackoverflow - und siehe da, es gibt eine Reihe von Drittanbieter-Authentifizierungsoptionen, einschließlich Facebook und Twitter. Am Ende entschied ich mich, meine Google-ID (die eine OpenID ist) zu verwenden, genau aus dem Grund, dass ich keinen Stackoverflow-Zugriff auf meine Freundesliste gewähren wollte und alles, was Facebook über seine Nutzer weitergibt - aber zumindest ist es ein Beweis dafür, dass OAuth für die von mir beabsichtigte Verwendung angemessen ist.

Es wäre wirklich großartig, wenn jemand Infos oder Hinweise zu Informationen über die Unterstützung dieser Art von 3rd-part-Autorisierungseinstellungen posten könnte und wie man mit Benutzern umgeht, die Autorisierung widerrufen oder den Zugriff auf ihre 3rd-Party-Site verlieren. Ich habe auch den Eindruck, dass mein Benutzername hier ein eindeutiges Stack-Overflow-Konto identifiziert, auf das ich mit Basisauthentifizierung zugreifen könnte, wenn ich es einrichten möchte, und auch auf dieses Konto durch andere Drittanbieterauthentifizierer zugreift (zB damit ich als eingeloggt betrachtet werde) in stackoverflow, wenn ich bei Google, Facebook oder Twitter angemeldet war ...). Da diese Seite es tut, hat jemand hier wahrscheinlich ziemlich gute Einsichten in das Thema. :-)

Entschuldigung, das war so lange und mehr eine Frage als eine Antwort - aber Karls Bemerkung ließ es als den am besten geeigneten Ort erscheinen, um inmitten der Menge von Threads auf OAuth und OpenID zu posten. Wenn es einen besseren Platz dafür gibt, den ich nicht gefunden habe, entschuldige ich mich im Voraus, ich habe es versucht.


11
2017-10-30 20:38



Die Erklärung des Unterschieds zwischen OpenID, OAuth, OpenID Connect:

OpenID ist ein Protokoll für die Authentifizierung während OAuth für   Genehmigung. Bei der Authentifizierung geht es darum sicherzustellen, dass der Typ Sie   mit denen zu reden ist in der Tat, wer er zu sein behauptet. Autorisierung geht um   Entscheiden, was dieser Typ tun sollte.

In OpenID wird die Authentifizierung delegiert: Server A möchte sich authentifizieren   Benutzer U, aber die Anmeldeinformationen von U (z. B. der Name und das Kennwort von U) werden an gesendet   ein anderer Server, B, dem A vertraut (vertraut zumindest auf die Authentifizierung)   Benutzer). Tatsächlich stellt Server B sicher, dass U tatsächlich U ist, und sagt dann   zu A: "Ok, das ist das echte U".

In OAuth wird die Autorisierung delegiert: Entität A erhält von Entität B   ein "Zugriffsrecht", das A dem Server S zeigen kann, um Zugriff zu erhalten; B   kann also temporäre, spezifische Zugangsschlüssel zu A liefern, ohne zu geben   sie zu viel Macht. Sie können sich einen OAuth-Server als Schlüsselmaster vorstellen   in einem großen Hotel; er gibt Angestellten Schlüssel, die die Türen des öffnen   Räume, in die sie eintreten sollen, aber jeder Schlüssel ist begrenzt (it   gibt keinen Zugang zu allen Räumen); außerdem die Schlüssel   Selbstzerstörung nach ein paar Stunden.

Bis zu einem gewissen Grad kann Autorisierung in einigen missbraucht werden   Pseudoauthentifizierung, auf der Grundlage, dass, wenn Entität A von B an erhält   Zugriffsschlüssel über OAuth, und zeigt es an Server S, dann Server S kann   folgern, dass B vor dem Gewähren des Zugriffsschlüssels A authentifiziert hat. So einige   Leute benutzen OAuth, wo sie OpenID benutzen sollten. Dieses Schema kann oder   möglicherweise nicht aufschlussreich; aber ich denke diese Pseudo-Authentifizierung ist   mehr verwirrend als alles andere. OpenID Connect macht genau das: Es missbraucht   OAuth in ein Authentifizierungsprotokoll. In der Hotelanalogie: wenn ich   Begegnung mit einem angeblichen Angestellten und diese Person zeigt mir, dass er eine hat   Schlüssel, der mein Zimmer öffnet, dann nehme ich an, dass dies ein echter Mitarbeiter ist,   auf der Grundlage, dass der Schlüsselmeister ihm keinen Schlüssel gegeben hätte, der   öffnet mein Zimmer, wenn er nicht war.

(Quelle)

Wie unterscheidet sich OpenID Connect von OpenID 2.0?

OpenID Connect führt viele der gleichen Aufgaben wie OpenID 2.0 aus, tut dies aber   also in einer Weise, die API-freundlich und von nativ und mobil nutzbar ist   Anwendungen. OpenID Connect definiert optionale Mechanismen für robust   Signieren und Verschlüsseln. Während der Integration von OAuth 1.0a und OpenID   2.0 benötigt eine Erweiterung, in OpenID Connect sind OAuth 2.0-Funktionen in das Protokoll selbst integriert.

(Quelle)

OpenID Connect wird Ihnen ein Zugriffs-Token plus ein ID-Token geben. Die ID   Token ist ein JWT und enthält Informationen über den authentifizierten Benutzer.   Es ist vom Identity Provider signiert und kann gelesen und verifiziert werden   ohne auf den Identity-Provider zuzugreifen.

Darüber hinaus standardisiert OpenID Connect einige Dinge   oauth2 überlässt die Wahl. zum Beispiel Bereiche, Endpunkt-Erkennung,   und dynamische Registrierung von Kunden.

Dies macht es einfacher, Code zu schreiben, zwischen dem der Benutzer wählen kann   mehrere Identitätsanbieter

(Quelle)

Google OAuth 2.0

Die OAuth 2.0-APIs von Google können sowohl für die Authentifizierung als auch für die Authentifizierung verwendet werden   Genehmigung. Dieses Dokument beschreibt unsere OAuth 2.0-Implementierung   für die Authentifizierung, die der OpenID Connect entspricht   Spezifikation und ist OpenID-zertifiziert. Die Dokumentation gefunden in    Verwenden von OAuth 2.0 für den Zugriff auf Google APIs gilt auch für diesen Service. Ob   Wenn Sie dieses Protokoll interaktiv erkunden möchten, empfehlen wir Ihnen das    Google OAuth 2.0-Spielplatz.

(Quelle)


10
2017-12-26 11:41