it-swarm.com.de

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 verschiedene Dinge?

859
Micah

OpenID handelt von Authentifizierung (dh Sie beweisen wer Sie sind), OAuth Es handelt sich um Autorisierung (dh, Zugriff auf Funktionalität/Daten/etc .. zu gewähren, ohne sich mit der ursprünglichen Authentifizierung befassen zu müssen).

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

Der Blogbeitrag " OpenID versus OAuth aus Sicht des Benutzers " enthält einen einfachen Vergleich der beiden aus Benutzersicht und " OAuth-OpenID: Sie bellen den falschen Baum an, wenn Sie der Meinung sind, dass sie es sind Same Thing "enthält weitere Informationen dazu.

739
adrianbanks

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

1. Zwecke

OpenID wurde für die Verbundauthentifizierung erstellt, das heißt, Sie lassen einen Benutzer von Drittanbietern für Ihre Benutzer authentifizieren, indem Sie Konten verwenden, die bereits über verfügen. Der Begriff "föderiert" ist hier kritisch, da es bei OpenID darum geht, dass alle Anbieter verwendet werden können (mit Ausnahme von Whitelists). Sie müssen keine Vereinbarung mit den Providern treffen oder aushandeln, um Benutzern die Verwendung anderer Konten zu ermöglichen.

OAuth wurde erstellt, um zu vermeiden, dass Benutzer ihre Kennwörter für Anwendungen von Drittanbietern freigeben müssen . Es begann eigentlich 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 auf Ihrer Site kein Kennwort haben.

Das Problem ist bei dieser Trennung von OpenID für Authentifizierung und OAuth für Autorisierung, dass beide Protokolle viele der gleichen Aufgaben erfüllen können. Sie bieten jeweils einen anderen Satz von Funktionen, die von verschiedenen Implementierungen gewünscht werden, aber im Wesentlichen sind sie ziemlich austauschbar. Beide Protokolle sind im Kern eine Assertionsverifikationsmethode (OpenID ist auf die Assetion "this is who who am" beschränkt, während OAuth ein "Access-Token" bereitstellt, das für jede unterstützte Assertion über eine API ausgetauscht werden kann).

2. Funktionen

Beide Protokolle bieten einer Site die Möglichkeit, einen Benutzer an einen anderen Ort umzuleiten und mit einer überprüfbaren Bestätigung zurückzukehren.OpenID stellt eine Identitätsbestätigung bereit, 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 Funktionen:

OpenID - Die wichtigste Funktion von OpenID ist der Erkennungsprozess. OpenID erfordert nicht für jeden Provider, den Sie vorab verwenden möchten, eine feste Codierung. Bei der Erkennung kann der Benutzer einen beliebigen Drittanbieter auswählen, den er authentifizieren möchte. Diese Erkennungsfunktion hat auch die meisten Probleme von OpenID verursacht, da sie so implementiert wird, dass HTTP-URIs als Bezeichner verwendet werden, die die meisten Webbenutzer nicht erhalten. Weitere Features, die OpenID unterstützt, ist die Unterstützung der Ad-hoc-Client-Registrierung über einen DH-Austausch, der sofortige Modus für ein optimiertes Endbenutzererlebnis und die Möglichkeit, Bestätigungen zu überprüfen, ohne einen weiteren Round-Trip zum Anbieter zu unternehmen.

OAuth - Das wichtigste Merkmal von OAuth ist das Zugriffstoken, das eine dauerhafte Methode für zusätzliche Anfragen darstellt. Im Gegensatz zu OpenID endet OAuth nicht mit der Authentifizierung, sondern stellt ein Zugriffstoken bereit, um auf zusätzliche Ressourcen zuzugreifen, 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 hartcodiert werden. Ein Benutzer, der Ihre Site besucht, kann keine Kennung verwenden, nur die von Ihnen zuvor ausgewählten. Außerdem hat OAuth kein Identitätskonzept. Wenn Sie es für die Anmeldung verwenden, müssen Sie entweder einen benutzerdefinierten Parameter hinzufügen (wie von Twitter ausgeführt) oder einen anderen API-Aufruf ausführen, um den derzeit "angemeldeten" Benutzer abzurufen.

3. Technische Implementierungen

Die beiden Protokolle weisen eine gemeinsame Architektur auf, indem sie die Umleitung verwenden, um eine Benutzerautorisierung zu erhalten. In OAuth berechtigt der Benutzer den Zugriff auf seine geschützten Ressourcen und in OpenID auf deren Identität. Aber das ist alles, was sie teilen.

Jedes Protokoll hat eine andere Methode zum Berechnen einer Signatur, die zur Überprüfung der Authentizität der Anforderung oder Antwort verwendet wird, und jedes Protokoll hat andere Registrierungsanforderungen.

334
Eran Hammer

OpenID dient (hauptsächlich) zur Identifikation/Authentifizierung, so dass stackoverflow.com weiß, dass ich chris.boyle.name (oder wo auch immer) besitze und daher wahrscheinlich ich dieselbe Person bin, die gestern chris.boyle.name besaß und einige Reputationspunkte erworben hat.

OAuth ist für die Autorisierung von Aktionen in Ihrem Namen konzipiert, sodass stackoverflow.com (oder wo auch immer) automatisch um Erlaubnis bittet, beispielsweise in Ihrem Namen zu twittern, ohne Ihr Twitter-Passwort zu kennen.

99
Chris Boyle

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

OpenID_vs._pseudo-authentication_using_OAuth

Mit freundlicher Genehmigung von Wikipedia

79
Vrashabh Irde

OAuth  

Wird nur für delegierteauthorizationverwendet. Dies bedeutet, dass Sie einem Drittanbieter-Service den Zugriff auf die persönlichen Daten erlauben, ohne ein Kennwort zu vergeben. Auch OAuth-"Sitzungen" leben im Allgemeinen länger als Benutzersitzungen. Das bedeutet, dass OAuth die Autorisierung zulässt

flickr verwendet OAuth, um Drittanbieter-Services zu ermöglichen, ein Personenbild in ihrem Namen zu veröffentlichen und zu bearbeiten, ohne dass sie ihren Flicker-Benutzernamen und ihr Kennwort angeben müssen.

OpenID

Wird verwendet, umauthenticateSingle-Sign-On-Identität zu verwenden. Alles, was OpenID tun soll, ist einem OpenID-Anbieter zu erlauben, zu beweisen, dass Sie dies als Ihre Aussage bezeichnen. Viele Standorte verwenden jedoch die Identitätsauthentifizierung, um eine Autorisierung bereitzustellen (die beiden können jedoch getrennt werden).

eine zeigt ihren Pass am Flughafen an, um sich zu authentifizieren (oder zu beweisen), wer der Name der Person auf dem Ticket ist, das sie benutzen. 

39
null

Verwenden Sie OAuth, wenn Ihre Benutzer sich nur bei Facebook oder Twitter anmelden möchten. Verwenden Sie OpenID, wenn Ihre Benutzer Nackenbären sind, die ihre eigenen OpenID-Provider betreiben, weil sie "nicht wollen, dass andere Personen ihre Identität besitzen".

31

OpenID und OAuth sind jeweils HTTP-basierte Protokolle zur Authentifizierung und/oder Autorisierung. Beides soll Benutzern die Ausführung von Aktionen ermöglichen, ohne dass Authentifizierungsnachweise oder allgemeine Berechtigungen an Clients oder Dritte vergeben werden. Obwohl sie ähnlich sind und es vorgeschlagen wird, beide Standards zusammen zu verwenden, handelt es sich dabei um separate Protokolle.

OpenID ist für die Verbundauthentifizierung vorgesehen. Ein Kunde akzeptiert eine Identitätsbestätigung von einem beliebigen Anbieter (obwohl Kunden Whitelist- oder Blacklist-Anbieter frei sind).

OAuth ist für die delegierte Autorisierung vorgesehen. Ein Client registriert sich bei einem Anbieter, der Autorisierungstoken zur Verfügung stellt, die er akzeptiert, um Aktionen für den Benutzer auszuführen.

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

17
Karl Anderson

Ich denke, es ist sinnvoll, diese Frage erneut zu prüfen, da auch in den Kommentaren darauf hingewiesen wurde, dass die Einführung von OpenID Connect möglicherweise mehr Verwirrung gebracht hat.

OpenID Connect ist ein Authentifizierungsprotokoll wie OpenID 1.0/2.0, das jedoch auf OAuth 2.0 aufbaut. Sie erhalten also Autorisierungsfunktionen und Authentifizierungsfunktionen. Der Unterschied zwischen den beiden wird in diesem (relativ jungen, aber wichtigen) Artikel ziemlich genau erklärt: http://oauth.net/articles/authentication/

14
Hans Z.

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

OpenID ist ein Protokoll zur Authentifizierung, während OAuth für .__ ist. Genehmigung. Bei der Authentifizierung geht es darum sicherzustellen, dass der Kerl Sie mit denen spricht er ist in der Tat er behauptet zu sein. Die Autorisierung ist etwa zu entscheiden, was dieser Kerl tun sollte.

In OpenID wird die Authentifizierung delegiert: Server A möchte sich authentifizieren Benutzer U, aber die Anmeldeinformationen von U (z. B. Name und Kennwort von U) werden an .__ gesendet. ein anderer Server B, dem A vertraut (zumindest für die Authentifizierung von Benutzern). Server B stellt tatsächlich sicher, dass U tatsächlich U ist, und teilt dann mit 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 somit temporäre, spezifische Zugangsschlüssel für A ausliefern, ohne Ihnen zu viel Kraft. Sie können sich einen OAuth-Server als Schlüsselmaster vorstellen in einem großen Hotel; er gibt den Mitarbeitern Schlüssel, die die Türen des .__ öffnen. Räume, die sie betreten sollen, aber jeder Schlüssel ist begrenzt (er gibt keinen Zugang zu allen Räumen); außerdem die tasten Selbstzerstörung nach wenigen Stunden.

Bis zu einem gewissen Grad kann die Autorisierung in einigen .__ missbraucht werden. Pseudo-Authentifizierung, auf der Grundlage, dass die Entität A von B eine .__ erhält. Zugriffstaste über OAuth und zeigt es Server S, dann kann Server S dass sich A authentifiziert, bevor der Zugriffsschlüssel erteilt wird. Also einige Menschen verwenden OAuth, wo sie OpenID verwenden sollten. Dieses Schema kann oder kann nicht erleuchtend sein; aber ich denke, diese Pseudo-Authentifizierung ist verwirrender als alles andere. OpenID Connect macht genau das: es missbraucht OAuth in ein Authentifizierungsprotokoll. In der Hotel-Analogie: Wenn ich einem angeblichen Mitarbeiter begegnen und diese Person zeigt mir, dass er eine .__ hat. Schlüssel, der mein Zimmer öffnet, dann nehme ich an, dass dies ein echter Angestellter ist. auf der Grundlage, dass der Schlüsselmeister ihm keinen Schlüssel gegeben hätte, der öffnet mein Zimmer, wenn er nicht wäre.

(Quelle)

Wie unterscheidet sich OpenID Connect von OpenID 2.0?

OpenID Connect führt viele der gleichen Aufgaben wie OpenID 2.0 aus, tut jedoch auf eine Weise, die API-freundlich ist und von native und mobile verwendet werden kann Anwendungen. OpenID Connect definiert optionale Mechanismen für robustes signieren und verschlüsseln. Die Integration von OAuth 1.0a und OpenID 2.0 erforderte eine Erweiterung. In OpenID Connect sind OAuth 2.0-Funktionen in das Protokoll selbst integriert.

(Quelle)

OpenID connect gibt Ihnen ein Zugriffstoken plus ein ID-Token. Die ID Token ist eine JWT und enthält Informationen zum authentifizierten Benutzer . Es ist vom Identitätsanbieter signiert und kann gelesen und verifiziert werden ohne auf den Identitätsanbieter zuzugreifen.

Darüber hinaus standardisiert OpenID Connect einige Dinge, die oauth2 lässt die Wahl. B. Bereiche, Endpunkterkennung, und dynamische Registrierung von Kunden.

Dies erleichtert das Schreiben von Code, mit dem der Benutzer zwischen .__ wählen kann. mehrere Identitätsanbieter.

(Quelle)

OAuth 2.0 von Google

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

(Quelle)

12
artamonovdev

Es handelt sich eher um eine Erweiterung der Frage als um eine Antwort, aber es kann den oben genannten technischen Antworten etwas Perspektive verleihen. Ich bin ein erfahrener Programmierer in einer Reihe von Bereichen, aber ein absolutes Noob für das Programmieren für das Web. Versuchen Sie jetzt, eine webbasierte Anwendung mit Zend Framework zu erstellen. 

Definiert definitiv eine anwendungsspezifische Basisbenutzer/Passwort-Authentifizierungsschnittstelle, erkennt jedoch an, dass für eine wachsende Anzahl von Benutzern der Gedanke an einen weiteren Benutzernamen und ein Passwort einen Abschreckungsangriff darstellt. Ich weiß zwar nicht gerade über soziale Netzwerke, aber ich weiß, dass ein sehr großer Prozentsatz der potenziellen Benutzer der Anwendung bereits über Facebook- oder Twitter-Konten verfügt. Die Anwendung möchte oder muss nicht wirklich auf Informationen über das Konto des Benutzers von diesen Websites aus zugreifen. Sie möchte lediglich die Bequemlichkeit bieten, dass der Benutzer keine neuen Kontoanmeldeinformationen einrichten muss, wenn er dies nicht möchte. Aus funktionaler Sicht erscheint das für OpenID wie ein Aushängeschild. Es scheint jedoch, dass weder Facebook noch Twitter OpenID-Anbieter sind, obwohl sie die OAuth-Authentifizierung für den Zugriff auf die Daten ihrer Benutzer unterstützen.

In allen Artikeln, die ich über die beiden gelesen habe, und darüber, wie sie sich unterscheiden, war es bis zu meiner Beobachtung von Karl Anderson oben, dass "OAuth zur Authentifizierung verwendet werden kann, was als eine No-Op-Autorisierung gedacht werden kann" Ich sah jede ausdrückliche Bestätigung, dass OAuth für das, was ich tun wollte, gut genug war.

Als ich diese "Antwort" veröffentlichte, die zu dieser Zeit noch kein Mitglied war, habe ich am Ende dieser Seite lange und intensiv nach den Möglichkeiten gesucht, mich zu identifizieren. Die Option, ein OpenID-Login zu verwenden oder einen zu erhalten, wenn ich keinen hatte, aber nichts über Twitter oder Facebook, schien zu vermuten, dass OAuth für den Job nicht geeignet war. Dann öffnete ich ein weiteres Fenster und suchte nach dem allgemeinen Anmeldeprozess für stackoverflow - und siehe da, es gibt eine Reihe von Authentifizierungsoptionen von Drittanbietern, einschließlich Facebook und Twitter. Am Ende entschied ich mich, meine Google-ID (eine OpenID) zu verwenden, aus genau dem Grund, dass ich stackoverflow keinen Zugriff auf meine Freundesliste gewähren wollte, und alles andere, was Facebook gerne über seine Nutzer mitteilt - aber es ist zumindest ein Beweispunkt, dass OAuth für meine Verwendung angemessen ist.

Es wäre wirklich großartig, wenn jemand entweder Informationen oder Hinweise zu Informationen über die Unterstützung dieser Art von Einrichtung von Drittanbieter-Autorisierungen bereitstellen könnte und wie Sie mit Benutzern umgehen, die die Autorisierung widerrufen oder den Zugriff auf die Drittanbieter-Site verlieren. Ich habe auch den Eindruck, dass mein Benutzername hier ein eindeutiges Stackoverflow-Konto identifiziert, auf das ich mit der Standardauthentifizierung zugreifen kann, wenn ich es einrichten möchte, und dasselbe Konto auch über andere Authentifizierungsprogramme von Drittanbietern (z. B. so, dass ich als protokolliert betrachtet würde) in stackoverflow, wenn ich bei google, facebook oder Twitter angemeldet war ...). Da diese Seite dies tut, hat wahrscheinlich jemand hier einen ziemlich guten Einblick in das Thema. :-)

Tut mir leid, das war so lang und eher eine Frage als eine Antwort - aber die Bemerkung von Karl machte den Anschein, dass es der geeignetste Ort war, um inmitten der Threads von OAuth und OpenID zu posten. Wenn es einen besseren Ort dafür gibt, den ich nicht gefunden habe, entschuldige ich mich im Voraus, ich habe es versucht.

11
sootsnoot

Eine ID Entität (OpenID) und die andere ist Auth orization (OAuth), beide sind Open Standard.

OpenID Connect (OIDC) ist ein Authentifizierungsprotokoll, das auf der Spezifikationfamilie OAuth 2.0 (d. H. O pen Auth) basiert. Es verwendet einfache JSON-Web-Token (JWT), die Sie mit Flows erhalten, die den OAuth 2.0 - Spezifikationen entsprechen. OAuth ist direkt mit OpenID Connect (OIDC) verbunden, da OIDC eine auf OAuth 2.0 aufgebaute Authentifizierungsschicht ist.

Während es sich bei OAuth 2.0 um Ressourcenzugriff und -freigabe handelt, d. H. Um Autorisierung, handelt es sich bei OIDC um Benutzerauthentifizierung. Der Zweck besteht darin, Ihnen ein Login für mehrere Websites zu geben. Jedes Mal, wenn Sie sich mit OIDC bei einer Website anmelden müssen, werden Sie zu Ihrer OpenID-Site weitergeleitet, auf der Sie sich anmelden, und dann zur Website zurückgeleitet.

OpenID Connect (OIDC) ist eine Authentifizierungsschicht auf OAuth 2.0, einem Berechtigungsframework. Der Standard wird von der OpenID Foundation kontrolliert.

 enter image description here

Zum Beispiel, wenn Sie sich mit Ihrem Google-Konto bei Auth0 angemeldet haben, haben Sie OIDC verwendet. Wenn Sie sich erfolgreich bei Google authentifiziert haben und Auth0 für den Zugriff auf Ihre Informationen autorisieren, sendet Google Informationen an den Benutzer {Auth0 und die durchgeführte Authentifizierung. Diese Informationen werden in einem JSON Web Token (JWT) zurückgegeben. Sie erhalten ein Access-Token und auf Wunsch ein ID-Token. Token-Typen : Quelle: OpenID Connect

Analogie:
Eine Organisation verwendet eine ID-Karte zu Identifikationszwecken, und sie enthält Chips. Sie speichert Details zum Mitarbeiter zusammen mit Authorization, d. H. Dem Campus/Gate/ODC-Zugriff. ID Card fungieren als OIDC und Chip fungieren als OAuth. mehr Beispiele

5
Premraj

OpenID beweist wer du bist.

OAuth gewährt Zugriff auf die von der autorisierenden Partei bereitgestellten Funktionen.

3

Ich arbeite derzeit an OAuth 2.0 und OpenID connect spec. Also hier ist mein Verständnis: Früher waren sie:

  1. Bei OpenID handelt es sich um eine proprietäre Implementierung von Google, die Drittanbieteranwendungen zulässt, z. B. für Zeitungswebsites, bei denen Sie sich über Google anmelden und einen Artikel kommentieren können, und andere Verwendungszwecke. Im Wesentlichen also kein Passwort für die Zeitungswebsite. Lassen Sie mich hier eine Definition aufstellen, diese Herangehensweise im Enterprise-Ansatz wird als Föderation bezeichnet. Im Verbund haben Sie einen Server, auf dem Sie sich authentifizieren und autorisieren (IDP, Identity Provider) und in der Regel der Inhaber der Benutzeranmeldeinformationen. Die Client-Anwendung, bei der Sie geschäftlich tätig sind, wird als SP oder Service Provider bezeichnet. Wenn wir zum Beispiel derselben Zeitungswebsite zurückkehren, ist die Zeitungswebsite hier SP und Google ist IDP. Im Unternehmen wurde dieses Problem zuvor mit SAML gelöst. damals benutzte XML die Softwareindustrie. Von Webservices bis zur Konfiguration wurde also alles für XML verwendet. Daher haben wir SAML, ein vollständiges Verbundprotokoll
  2. OAuth: OAuth sah es als einen Standard an, der alle diese proprietären Ansätze betrachtet. Daher hatten wir OAuth 1.o als Standard, aber nur die Autorisierung. Nicht viele Leute bemerkten es, aber es fing an, sich abzuheben. Dann hatten wir 2012 OAuth 2.0. CTOs, Architects, begannen wirklich aufmerksam zu werden, da sich die Welt auf Cloud Computing und Computergeräte auf mobile Geräte und andere derartige Geräte ausrichtet. OAuth galt als eine Lösung für ein großes Problem, bei dem Software-Kunden einem Unternehmen IDP-Service anbieten könnten und über viele Dienste von verschiedenen Anbietern wie Salesforce, SAP usw. verfügen. Die Integration hier sieht also aus, als wäre das Verbundszenario ein großes Problem. Die Verwendung von SAML ist teuer Also lasst uns OAuth 2.o erkunden. Oh, verpasste einen wichtigen Punkt, dass Google während dieser Zeit spürte, dass OAuth die Authentifizierung nicht anspricht. Wie wird IDP Benutzerdaten an SP geben (was in SAML tatsächlich wunderbar angesprochen wird) und mit anderen losen Enden wie:

    ein. OAuth 2.o sagt nicht eindeutig aus, wie die Kundenregistrierung abläuft B. Es wird nichts über die Interaktion zwischen SP (Resource Server) und der Clientanwendung erwähnt (z. B. wenn Analytics Server Daten als Resource Server bereitstellt und die Anwendung anzeigt, dass die Daten Client sind).

Hier gibt es schon wundervolle Antworten, ich dachte daran, eine kurze Entwicklungsperspektive zu geben

1
dvsakgec

OAuth 2.0 ist ein Sicherheitsprotokoll. Es ist weder eine Authentifizierung NOR noch ein Autorisierungsprotokoll. 

Authentifizierung durch Definition der Antworten auf zwei Fragen.

  1. Wer ist der benutzer
  2. Ist der Benutzer derzeit auf dem System vorhanden?

OAuth 2.0 verfügt über die folgenden Zuschussarten

  • client_credentials: Wenn eine App mit einer anderen App interagieren und die Daten mehrerer Benutzer ändern muss.
  • berechtigungscode: Der Benutzer delegiert den Berechtigungsserver, um ein access_token auszugeben, das der Client für den Zugriff auf eine geschützte Ressource verwenden kann
  • refresh_token: Wenn das access_token abläuft, kann das Aktualisierungstoken genutzt werden, um ein neues access_token zu erhalten
  • kennwort: Der Benutzer gibt seine Anmeldeinformationen an einen Client weiter, der den Autorisierungsserver aufruft und ein access_token erhält

Alle 4 haben eines gemeinsam: access_token, ein Artefakt, mit dem auf geschützte Ressourcen zugegriffen werden kann.

Das access_token bietet keine Antwort auf die zwei Fragen, die ein "Authentication" -Protokoll beantworten muss. 

Ein Beispiel um Oauth 2.0 zu erklären (Credits: OAuth 2 in Action, Manning-Publikationen)

Lass uns über Schokolade reden. Wir können aus Schokolade viele Konfekte herstellen, darunter Fudge, Eis und Kuchen. Aber keine davon kann mit Schokolade gleichgesetzt werden, da zur Herstellung der Konfektion mehrere andere Zutaten wie Sahne und Brot benötigt werden, auch wenn Schokolade wie der Hauptbestandteil klingt. In ähnlicher Weise ist OAuth 2.0 die Schokolade und Kekse, TLS-Infrastruktur, Identitätsanbieter sind weitere Zutaten, die zur Bereitstellung der Authentifizierungsfunktion erforderlich sind.

Wenn Sie eine Authentifizierung wünschen, können Sie OpenID Connect wählen, das neben einem access_token ein "id_token" bereitstellt, das die Fragen beantwortet, die jedes Authentifizierungsprotokoll beantworten muss.

0
Rajat

Ich möchte auf einen bestimmten Aspekt dieser Frage eingehen, der in diesem Kommentar festgehalten ist:

OAuth: Bevor Sie Zugriff auf eine Funktion gewähren können, muss eine Authentifizierung durchgeführt werden, oder? also OAuth = was macht OpenId + gewährt Zugriff auf einige Funktionen? - Hassan Makarov 21. Juni um 1:57 Uhr

Ja und nein. Die Antwort ist subtil, also nimm sie mit.

Wenn der OAuth -Fluss Sie zu einem Zieldienst umleitet (dh zum OAuth -Anbieter), ist eswahrscheinlich, dass Sie muss sich bei diesem Dienst authentifizieren, bevor ein Token an die Clientanwendung/den Clientdienst zurückgegeben wird. Das resultierende Token ermöglicht es der Client-App, Anforderungen im Namen eines bestimmten Benutzers zu stellen.

Beachten Sie die Allgemeingültigkeit dieses letzten Satzes: Insbesondere schrieb ich "im Namen eines bestimmten Benutzers" not "im Namen von du". Es ist ein häufiger Fehler anzunehmen, dass "die Fähigkeit zur Interaktion mit einer Ressource eines bestimmten Benutzers" impliziert, dass Sie und der Eigentümer der Zielressource (n) eine Person sind ".

Machen Sie diesen Fehler nicht.

Während es wahr ist, dass Sie sich beim OAuth-Provider authentifizieren (z. B. über Benutzername und Passwort oder SSL-Client-Zertifikate oder auf andere Weise), sollte das, was der Client erhält,notmuss als Identitätsnachweis herangezogen werden. Ein Beispiel wäre ein Ablauf, in dem der Zugriff auf die Ressourcen eines anderen Benutzersdelegiertan Sie (und über einen Proxy an den OAuth -Client) erfolgte. Die Autorisierung impliziert keine Authentifizierung.

Um die Authentifizierung zu handhaben, sollten Sie sich mit OpenID Connect befassen, einer weiteren Ebene auf der Grundlage von OAuth 2.0. Hier ist ein Zitat, das (meiner Meinung nach) die wichtigsten Punkte in Bezug auf OpenID Connect erfasst (von https://oauth.net/articles/authentication/ ):

OpenID Connect ist ein Anfang 2014 veröffentlichter offener Standard, der eine interoperable Methode zur Verwendung von OAuth 2.0 für die Benutzerauthentifizierung definiert. Im Wesentlichen handelt es sich um ein weit verbreitetes Rezept für Schokoladenfondant, das von einer Vielzahl von Experten erprobt und getestet wurde. Anstatt für jeden potenziellen Identitätsanbieter ein anderes Protokoll zu erstellen, kann eine Anwendung ein Protokoll mit so vielen Anbietern sprechen, wie sie arbeiten möchten. Da es sich um einen offenen Standard handelt, kann OpenID Connect von jedem ohne Einschränkungen oder Bedenken hinsichtlich des geistigen Eigentums implementiert werden.

OpenID Connect baut direkt auf OAuth 2.0 auf und wird in den meisten Fällen direkt zusammen mit (oder zusätzlich zu) einer OAuth Infrastruktur bereitgestellt. OpenID Connect verwendet auch die JSON-Suite für Objektsignierung und -verschlüsselung (JOSE), um signierte und verschlüsselte Informationen an verschiedenen Orten zu transportieren. Tatsächlich ist eine OAuth 2.0-Bereitstellung mit JOSE-Funktionen bereits ein langer Weg, um ein vollständig kompatibles OpenID Connect-System zu definieren, und das Delta zwischen beiden ist relativ klein. Aber dieses Delta macht einen großen Unterschied, und OpenID Connect vermeidet viele der oben diskutierten Fallstricke, indem der OAuth -Basis mehrere Schlüsselkomponenten hinzugefügt werden: [...]

Das Dokument beschreibt dann (unter anderem) Token-IDs und einen UserInfo-Endpunkt. Ersteres enthält eine Reihe von Ansprüchen (wer Sie sind, wann der Token ausgestellt wurde usw.) und möglicherweise eine Signatur, um die Authentizität des Tokens über einen veröffentlichten öffentlichen Schlüssel zu überprüfen.without(Ich muss den vorgelagerten Dienst fragen), und letzterer bietet ein Mittel, um z Auf standardisierte Weise nach dem Vor-/Nachnamen, der E-Mail-Adresse und ähnlichen Informationen des Benutzers fragen (im Gegensatz zu den Ad-hoc-Erweiterungen für OAuth, die vor OpenID Connect verwendet wurden).

0
Charles

Beide Protokolle wurden aus verschiedenen Gründen erstellt. OAuth wurde erstellt, um Dritten den Zugriff auf Ressourcen zu ermöglichen. OpenID wurde erstellt, um die Identitätsprüfung dezentral durchzuführen. Diese Website gibt Folgendes an:

OAuth ist ein Protokoll, mit dem die Identität eines Endbenutzers überprüft und einem Dritten Berechtigungen erteilt werden können. Diese Überprüfung führt zu einem Token. Der Dritte kann dieses Token verwenden, um auf Ressourcen im Namen des Benutzers zuzugreifen. Token haben einen Gültigkeitsbereich. Der Bereich wird verwendet, um zu überprüfen, ob eine Ressource für einen Benutzer verfügbar ist oder nicht

OpenID ist ein Protokoll zur dezentralen Authentifizierung. Bei der Authentifizierung geht es um Identität. Die Bestimmung des Benutzers ist in der Tat die Person, die er vorgibt zu sein. Durch die Dezentralisierung bedeutet dies, dass der Dienst keine Ressourcen oder Anwendungen kennt, die geschützt werden müssen. Das ist der Hauptunterschied zwischen OAuth und OpenID.

0

OpenId verwendet OAuth für die Authentifizierung. 

Analog dazu ist es so, als ob .NET auf der Windows-API basiert. Sie können Windows-API direkt aufrufen, aber es ist so umfangreich, komplex und Methodenargumente, dass Sie leicht Fehler/Bugs/Sicherheitsprobleme machen können. 

Gleiches mit OpenId/OAuth. OpenId stützt sich bei der Authentifizierung auf OAuth, definiert jedoch ein bestimmtes Token (Id_token), eine digitale Signatur und bestimmte Flows.

0
Jerome