OpenID ist ein Protokoll für die Authentifizierung , während OAuth für die Autorisierung ist. Bei der Authentifizierung geht es darum, sicherzustellen, dass der Typ, mit dem Sie sprechen, tatsächlich der ist, für den er sich ausgibt. Bei der Autorisierung geht es darum, zu entscheiden, was dieser Typ tun darf.

In OpenID wird die Authentifizierung delegiert: Server A möchte Benutzer U authentifizieren, aber die Anmeldeinformationen von U (z. B. Name und Kennwort von U) werden an einen anderen Server gesendet , B, dass A vertraut (zumindest Vertrauensstellungen zur Authentifizierung von Benutzern). In der Tat stellt Server B sicher, dass U tatsächlich U ist, und teilt A dann mit: "OK, das ist das echte U".

In OAuth wird die Autorisierung delegiert: Entität A erhält von Entität B einen "Zugriff" rechts "welches A dem Server S zeigen kann, um Zugriff zu erhalten; B kann somit temporäre, spezifische Zugriffsschlüssel an A liefern, ohne ihnen zu viel Strom zu geben. Sie können sich einen OAuth-Server als Schlüsselmaster in einem großen Hotel vorstellen. Er gibt den Mitarbeitern Schlüssel, die die Türen der Räume öffnen, die sie betreten sollen, aber jeder Schlüssel ist begrenzt (er gewährt nicht Zugang zu allen Räumen). Darüber hinaus zerstören sich die Schlüssel nach einigen Stunden selbst.

Bis zu einem gewissen Grad kann die Autorisierung für eine Pseudoauthentifizierung missbraucht werden, auf der Grundlage, dass, wenn Entität A von B einen Zugriffsschlüssel über OAuth erhält, und zeigt es Server S an, dann kann Server S schließen , dass B A authentifiziert hat, bevor er den Zugriffsschlüssel gewährt. Einige Leute verwenden OAuth dort, wo sie OpenID verwenden sollten. Dieses Schema kann aufschlussreich sein oder auch nicht. Aber ich denke, diese Pseudoauthentifizierung ist verwirrender als alles andere. OpenID Connect macht genau das: Es missbraucht OAuth in einem Authentifizierungsprotokoll. In der Hotelanalogie: Wenn ich einem vermeintlichen Mitarbeiter begegne und dieser mir zeigt, dass er einen Schlüssel hat, der mein Zimmer öffnet, dann nehme ich an, dass dies ein echter Mitarbeiter ist, basierend auf dem Schlüsselmeister hätte ihm keinen Schlüssel gegeben, der mein Zimmer öffnet, wenn er es nicht wäre.

Einfache Begriffe

1. Bei OpenID geht es darum, die Identität einer Person zu überprüfen (Authentifizierung).
2. Bei OAuth geht es um den Zugriff auf das Zeug einer Person (Autorisierung).
3. OpenID Connect macht beides .
ol>

Alle drei lassen eine Person ihren Benutzernamen / ihr Passwort (oder andere Anmeldeinformationen) an eine vertrauenswürdige Behörde anstelle einer weniger vertrauenswürdigen App.

Weitere Details

Um etwas zu verstehen, schauen Sie sich seine Geschichte an.

OpenID & OAuth wurde auf parallelen Spuren entwickelt und 2014 zu OpenID Connect zusammengeführt. Im Laufe ihres Verlaufs haben OpenID und OAuth einer App die Verwendung einer vertrauenswürdigen Berechtigung zur Verarbeitung privater Benutzeranmeldeinformationen ermöglicht. Während OpenID die Autorität die Identität eines Benutzers überprüfen lässt, lässt OAuth die Autorität den eingeschränkten Zugriff auf die Inhalte eines Benutzers gewähren.

OpenID 1.0 (2006) ermöglicht es einer App, eine Behörde um den Nachweis zu bitten, dass ein Endbenutzer eine Identität (eine URL) besitzt.

• Endbenutzer für App: Ich bin Steve A. Smith.
• App für Autorität: Ist das Steve A. Smith?
• Der Endbenutzer und die Autorität sprechen für einen Moment.
• Berechtigung zur App: Ja, das ist Steve A. Smith.

OpenID 2.0 (2007) macht dasselbe, fügt jedoch ein zweites Identitätsformat (XRI) hinzu und erhöht die Flexibilität bei der Angabe der Identität und Berechtigung durch den Endbenutzer.

OpenID Attribute Exchange 1.0 (2007) erweitert OpenID 2.0, indem eine App &-Informationen zum Endbenutzerprofil mit der Berechtigung abruft - zusätzlich zur Überprüfung der Identität des Endbenutzers.

• Endbenutzer zur App: Ich bin Steve A. Smith.
• App an die Behörde: Ist das Steve A. Smith? Oh, und wenn ja, holen Sie mir auch seine E-Mail-Adresse und Telefonnummer.
• Der Endbenutzer und die Autorität sprechen einen Moment.
• Autorität zu App: Ja, das ist Steve A. Smith. Seine E-Mail lautet steve@domain.com und die Telefonnummer lautet 123-456-7890.

OAuth 1.0 (2010) kann ein Endbenutzer einer App eingeschränkten Zugriff auf Ressourcen auf einem Server eines Drittanbieters gewähren, dessen Eigentümer eine Behörde ist.

• App für Endbenutzer: Wir möchten auf einem anderen Server auf Ihre Bilder zugreifen.
• Der Endbenutzer und die Autorität sprechen einen Moment.
• Berechtigung zur App: Hier ist ein Zugriffstoken.
• App zum Server eines Drittanbieters: Hier ist das Zugriffstoken, das beweist, dass ich für einen Endbenutzer auf Bilder zugreifen darf.

OAuth 2.0 (2012) macht dasselbe wie OAuth 1.0, jedoch mit einem völlig neuen Protokoll.

OpenID Connect (2014) kombiniert die Funktionen von OpenID 2.0, OpenID Attribute Exchange 1.0 und OAuth 2.0 in einem einzigen Protokoll. Es ermöglicht einer Anwendung, eine Berechtigung zu verwenden ...

1. , um die Identität des Endbenutzers zu überprüfen,
2. um die Profilinformationen des Endbenutzers abzurufen, und
3. um eingeschränkten Zugriff auf die Inhalte des Endbenutzers zu erhalten.
ol>

Viele Leute besuchen dies immer noch. Hier ist ein sehr einfaches Diagramm, um es zu erklären.

Mit freundlicher Genehmigung von Wikipedia

Wir haben bereits ein Diagramm und viele gute Daten. Hier ist ein Beispiel für den Fall, dass dies hilfreich ist.

Angenommen, ich möchte einen Kommentar zu StackOverflow senden. StackOverflow erlaubt nur Kommentare, wenn ein Benutzer 50 Reputationen hat.

StackOverflow muss diese Anforderung autorisieren (z. B. nur zulassen, wenn der Benutzer> = 50 Wiederholungen hat). StackOverflow würde OAuth nicht verwenden, da StackOverflow die geschützte Ressource besitzt. Wenn StackOverflow versuchen würde, im Namen des Benutzers einen Kommentar auf Facebook zu veröffentlichen, würde OAuth verwendet. Stattdessen verwendet StackOverflow die lokale Autorisierung (z. B. if (user.reputation < 50) throw InsufficientReputationError (); )

Um dies zu tun, muss StackOverflow zuerst wissen, wer das macht Anfrage. Mit anderen Worten, um die Anforderung zu autorisieren, muss sie zuerst authentifizieren die Anforderung.

StackOverflow überprüft zuerst die Sitzung und die HTTP-Header, um festzustellen, ob der Benutzer schnell authentifiziert werden kann ( Beispiel: Dies ist nicht ihre erste Anforderung. Dies schlägt jedoch fehl.

Stellen wir uns vor, StackOverflow hat sich für OpenID Connect entschieden. Dies bedeutet, dass StackOverflow einem Identitätsanbieter vertraut. Dies ist ein Dienst, dem StackOverflow vertraut und der StackOverflow mitteilen kann, wer der aktuelle Benutzer ist. In diesem Beispiel wird davon ausgegangen, dass es sich um Google handelt.

StackOverflow fragt Google jetzt, wer der aktuelle Nutzer ist. Google muss jedoch zunächst sicherstellen, dass StackOverflow wissen darf, wer der aktuelle Nutzer ist. Mit anderen Worten, Google muss StackOverflow autorisieren . Da Google der Eigentümer der geschützten Ressource ist und StackOverflow derjenige ist, der darauf zugreift, können wir hier OAuth verwenden. Tatsächlich schreibt OpenID Connect dies vor.

Dies bedeutet, dass sich StackOverflow bei einem Autorisierungsserver authentifizieren muss, dem Google vertraut (in Wirklichkeit wäre dies auch Google, dies muss jedoch nicht der Fall sein) und ein Zugriffstoken erhalten muss . Es nimmt dieses Zugriffstoken zu Google und fragt nach der Identität des Nutzers. Google gibt dann die Identität des Nutzers zurück (Signieren der Identität auf dem Weg) und StackOverflow autorisiert die Anfrage, sobald die Identität des Nutzers bekannt ist.

Falls Sie sie verpasst haben, wurden jeweils mehrere Authentifizierungs- und Autorisierungsschritte ausgeführt.

• StackOverflow hat versucht, die Anforderung mithilfe von Sitzungscookies zu authentifizieren , dies ist jedoch fehlgeschlagen.
• StackOverflow hat dann die Anforderung mithilfe von authentifiziert OpenID Connect
• Google autorisierte SO-Identitätsanforderung mithilfe von OAuth
• Der Autorisierungsserver authentifizierte StackOverflow (wahrscheinlich unter Verwendung einer Client-ID &-Client-Geheimnis).
• Im Rahmen des OAuth-Workflows hat der Autorisierungsserver die Anforderung möglicherweise authentifiziert , indem er den Benutzer nach seinem Benutzernamen &-Kennwort fragt.
• Darüber hinaus hat der Benutzer möglicherweise selbst die autorisierte SO-Identitätsanfrage durch Beantwortung eines Zuschusses Bildschirm (z. "Möchten Sie StackOverflow Zugriff auf Ihre E-Mail gewähren?")
• StackOverflow hat die Anforderung autorisiert , indem sichergestellt wurde, dass der Benutzer über> 50 Reputation verfügt.

Was ist OpenID (ohne Verbindung)?

Dies war ein früheres Protokoll, mit dem ein Identitätsanbieter (wie Google) Benutzerinformationen an einen Dienst (wie StackOverflow) weitergeben konnte. Es wurde jedoch eine andere Methode (nicht OAuth) für Google verwendet, um zu autorisieren, dass StackOverflow auf die Identität des Benutzers zugreifen darf. OpenID hatte einige Sicherheitslücken (von denen ich glaube, dass sie behoben wurden), aber meiner Meinung nach war der wahre Killer einfach die Tatsache, dass OAuth eine bessere Unterstützung hatte und daher tendenziell weniger Arbeit als das Erlernen des benutzerdefinierten Protokolls von OpenID.

Ab heute gibt es jeder auf. Benutze es nicht. Verwenden Sie OpenID Connect.

OAuth "missbrauchen"

In dem oben beschriebenen Szenario wird OAuth genau so verwendet, wie es für die Autorisierung vorgesehen ist. Es gibt jedoch einen anderen Workflow, der Menschen oft verwirren kann. Dies ist darauf zurückzuführen, dass in vielen Situationen (meistens?) Der Server, der die Identität des Benutzers bereitstellt, und der OAuth-Autorisierungsserver derselbe Server sind.

In diesem Fall scheint es etwas übertrieben, dass zuerst eine HTTP-Anforderung an den Server gesendet wird Autorisierungsserver, um ein Zugriffstoken zu erhalten, und dann erneut an denselben Server gesendet, um ein Identitätstoken zu erhalten. Daher wurde für die OAuth-Spezifikation eine -Erweiterung erstellt, damit der Autorisierungsserver Benutzeridentitätsinformationen mit dem Zugriffstoken bündeln kann.

Dadurch kann die Authentifizierung vollständig im Browser erfolgen (z. B. bei StackOverflow) Server müssen nicht beteiligt sein). Diese Art der Authentifizierung ist jedoch weniger nützlich und wird (glaube ich?) Weniger häufig verwendet.

Zusätzlich zu den anderen Antworten: Ich denke, dass viel Verwirrung durch ungenaue oder zumindest ungewöhnliche Verwendung der Begriffe Authentifizierung und Autorisierung

OpenID Connect 1.0 wird als Authentifizierungslösung vermarktet, während es die Authentifizierung nicht selbst übernimmt. Die "echte" Authentifizierung in ihrem grundlegenden Sinne (Prozess der Überprüfung der Benutzeranmeldeinformationen zum Nachweis einer Identität ) fällt nicht in den Geltungsbereich von OpenID Connect.

OpenID Connect sollte besser als vermarktet werden ein Federation -Protokoll, mit dem eine vertrauende Partei den vorhandenen Authentifizierungsprozess, die Benutzerdatenbank und die Sitzungsbehandlung eines ID-Anbieters eines Drittanbieters verwenden kann. Das ist funktional ähnlich wie bei SAML 2.0.

Hinweis: Aus Sicht der vertrauenden Partei kann das Erhalten und Validieren eines ID-Tokens von einem ID-Anbieter streng genommen als Authentifizierungsmethode betrachtet werden. Ich glaube, hier kommt "OpenID Connect ist ein Authentifizierungsprotokoll" her.

Dieselbe Argumentation für OAuth 2.0 als Authorization -Protokoll: In der Regel wird die Autorisierung definiert Eine Zugriffsrichtlinie, die bestimmt, welche Benutzer Zugriff auf welche Ressourcen haben. Diese Definition gilt kaum für OAuth.

OAuth 2.0 bietet Benutzern tatsächlich die Möglichkeit, einer Anwendung / einem Client den Zugriff auf ihre eigenen Ressourcen in ihrem Namen zu ermöglichen. Mit anderen Worten, OAuth 2.0 autorisiert Clients -Anwendungen, nicht Benutzer, zum Zugriff auf die Ressourcen. Die Autorisierungsrichtlinie (Gewähren von Benutzern Zugriff auf Ressourcen) sollte vor der Bereitstellung von OAuth vorhanden sein.

Ich hätte OAuth als Zugriffsdelegationsprotokoll bezeichnet.

Ich entschuldige mich, wenn dieser Beitrag die Verwirrung noch weiter erhöht :)

Wie bereits erwähnt, ist Oauth eine Sache, OpenID eine andere und OpenID Connect kombiniert beide.

Wie bereits erwähnt, ist die Verwendung von Authentifizierung und Autorisierung zur Unterscheidung von Oauth und OpenID einfach falsch. Die Authentifizierung, die Bestätigung der Richtigkeit des Anspruchs eines Unternehmens auf eine gespeicherte Identität, wird OpenID zugeordnet, ist jedoch definitiv Teil des Oauth-Prozesses. Die Berechtigung, die Berechtigung zum Zugriff auf eine bestimmte Ressource oder einen bestimmten Container, wird Oauth zugewiesen, ist jedoch definitiv Teil des OpenID-Prozesses.

Nach meiner Erfahrung ist der tatsächliche Unterschied zwischen Oauth und OpenID im typischen Non zu erkennen -auth-bezogene Aktivitäten, die von wem im Rahmen jedes Programms durchgeführt werden.

• OpenID erleichtert dem Benutzer den Zugriff auf einen berechtigten Container mit gebündelten Ressourcen (z. B. Website-Zugriff).
• Oauth erleichtert den automatisierten Zugriff auf eine berechtigte Ressource innerhalb eines Containers (z. B. CRUD-Operationen in einer Datei oder Aufzeichnung über eine Web-API).

OpenID Connect ermöglicht dies dann Wenn ein Benutzer auf eine Webadresse zugreift und diese einmal aktiviert hat, kann die zugrunde liegende Webanwendung im Namen des Benutzers zusätzliche externe Ressourcen abrufen.

Zusammenfassend: OpenID Connect ist eine Verbundidentitäts-API, die ein Profil und eine Erweiterung von OAuth 2.0 enthält, mit der ein Client (dh eine mobile App oder Website) eine Person zur Authentifizierung an einen zentralen Identitätsanbieter umleiten kann Autorisieren Sie die Freigabe von Informationen an diesen Client.

Sie sollten meinen Blog OAuth vs. SAML vs. OpenID Connect lesen: https://gluu.co/oauth- saml-openid

Die OpenID Connect-API enthält eine Reihe von Endpunkten, die nicht alle mit OAuth zusammenhängen:

OAuth-Endpunkte

• Autorisierung : Front-Channel-Website, auf der die Anmeldeseite und die Autorisierungsseite (Einwilligungsseite) gerendert werden. (RFC 6749)
• Token : Back-Channel-Endpunkt, für den normalerweise eine Authentifizierung erforderlich ist, bei dem ein Client Zugriffstoken, id_tokens und Aktualisierungstoken anfordern kann. (RFC 6749)
Konfiguration : Provider-Metadaten, die unter .well-bekannte / openid-Konfiguration veröffentlicht wurden, einschließlich der Position von Endpunkten, unterstützte kryptografische Algorithmen, und andere Informationen, die der Client für die Interaktion mit dem OP benötigt. (RFC 8414)
• Client-Registrierung : Endpunkt für eine Anwendung zum Erstellen oder Aktualisieren eines OAuth-Clients (RFC 7591)

Nicht-OAuth-Endpunkte

• Benutzerinfo : Zugriff auf tokengeschützte API, über die der Client Ansprüche zu einem Betreff anfordern kann. Dies ist der Ressourcenserver in OAuth-Begriffen.
• JWKS : Die aktuellen öffentlichen Schlüssel des OP, die zum Signieren und Verschlüsseln verwendet werden.
• Sitzungsverwaltung : Wird von allen drei OpenID-Abmeldespezifikationen verwendet (keine funktioniert so gut).
• Webfinger : Wird verwendet, um die OP-Erkennung von einer E-Mail-Adresse (oder einer anderen Kennung) rückwärts zu starten. dh wie ermitteln Sie den Konfigurationsendpunkt für eine Domäne? (RFC 7033, aber nicht Teil der OAuth WG)