Geekly articles weekly

Illustriertes OAuth- und OpenID Connect-Handbuch

Hinweis perev. : Dieser großartige Okta-Blogbeitrag erklärt OAuth und OIDC (OpenID Connect), wie es funktioniert. Dieses Wissen wird Entwicklern, Systemadministratoren und sogar "normalen Benutzern" von beliebten Webanwendungen nützlich sein, die höchstwahrscheinlich auch sensible Daten mit anderen Diensten austauschen.

In der Steinzeit des Internets war es einfach, Informationen zwischen Diensten auszutauschen. Sie haben einfach Ihren Benutzernamen und Ihr Passwort von einem Dienst an einen anderen weitergegeben, damit dieser Ihren Account betrat und alle erforderlichen Informationen erhielt.


"Geben Sie Ihr Bankkonto an." „Wir versprechen, dass mit dem Passwort und dem Geld alles in Ordnung sein wird. Das ist ehrlich ehrlich! "* Hee hee *

Horror! Niemand sollte von einem Benutzer verlangen, dass er seinen Benutzernamen und sein Kennwort sowie seine Anmeldeinformationen für einen anderen Dienst freigibt . Es gibt keine Garantie dafür, dass die Organisation, die hinter diesem Dienst steht, die Daten sicher verwahrt und nicht mehr personenbezogene Daten als erforderlich sammelt. Es mag wild erscheinen, aber bei einigen Anwendungen wird diese Praxis immer noch angewendet!

Heute gibt es einen einzigen Standard, mit dem ein Dienst die Daten eines anderen Dienstes sicher verwenden kann. Leider verwenden solche Standards viel Fachsprache und Begriffe, was ihr Verständnis erschwert. Der Zweck dieses Materials ist es, zu erklären, wie sie mit einfachen Illustrationen funktionieren. (Denken Sie, dass meine Zeichnungen einem Baby Daub ähneln? Nun, okay!).



Diese Anleitung gibt es übrigens auch im Videoformat:


Meine Damen und Herren, treffen Sie: OAuth 2.0


OAuth 2.0 ist ein Sicherheitsstandard, mit dem eine Anwendung die Berechtigung zum Zugriff auf Informationen in einer anderen Anwendung erhält. Die Abfolge der Schritte zum Erteilen einer Berechtigung (Erlaubnis ) wird häufig als Autorisierung oder sogar delegierte Autorisierung bezeichnet . Mit diesem Standard gestatten Sie einer Anwendung, Daten zu lesen oder die Funktionen einer anderen Anwendung in Ihrem Namen zu verwenden, ohne dass Sie Ihr Kennwort angeben müssen. Klasse!

Stellen Sie sich zum Beispiel vor, Sie hätten eine Site namens „ Terrible Pun of the Day“ entdeckt und sich dazu entschlossen, sich dort zu registrieren, um tägliche Wortspiele in Form von Textnachrichten auf Ihrem Telefon zu erhalten. Sie mochten die Website wirklich und haben beschlossen, sie mit all Ihren Freunden zu teilen. Immerhin schreckliche Wortspiele wie jeder andere, oder?


"Fehlgeschlagenes Wortspiel des Tages: Hast du von einem Typen gehört, der seine linke Körperhälfte verloren hat?" Jetzt hat er immer recht! “(Ungefähre Übersetzung, da das Original ein eigenes Wortspiel hat, - ca. Übersetzung.)

Es ist klar, dass das Schreiben an jede Person von der Kontaktliste keine Option ist. Und wenn Sie mir auch nur ein bisschen ähnlich sind, werden Sie alles tun, um unnötige Arbeit zu vermeiden. Glücklicherweise kann Terrible Pun of the Day alle deine Freunde alleine einladen! Dazu müssen Sie ihm lediglich Zugriff auf die E-Mail-Adresse der Kontakte gewähren - die Site selbst sendet ihnen Einladungen (OAuth-Laufwerke)!


"Jeder liebt Wortspiele!" - Bereits eingeloggt? - Möchten Sie die Website "Terrible Pun of the Day" mit Ihrer Kontaktliste teilen? - Vielen Dank! Jetzt senden wir jeden Tag Erinnerungen an alle, die Sie kennen, bis zum Ende der Zeit! Du bist der beste Freund! "

  1. Wählen Sie Ihren E-Mail-Dienst.
  2. Rufen Sie bei Bedarf die E-Mail-Site auf und melden Sie sich bei Ihrem Konto an.
  3. Erteilen Sie Terrible Pun of the Day die Erlaubnis, auf Ihre Kontakte zuzugreifen.
  4. Kehren Sie zur Website "Terrible Pun of the Day" zurück.

Für den Fall, dass Sie Ihre Meinung ändern, bieten Anwendungen, die OAuth verwenden, auch eine Möglichkeit, den Zugriff zu widerrufen. Nachdem Sie entschieden haben, dass Sie keine Kontakte mehr mit Terrible Pun of the Day teilen möchten, können Sie zur E-Mail-Site gehen und die Site mit Wortspielen aus der Liste der autorisierten Anwendungen löschen.

OAuth Stream


Wir haben gerade den sogenannten OAuth [flow] Stream durchlaufen. In unserem Beispiel besteht dieser Ablauf aus sichtbaren Schritten sowie mehreren unsichtbaren Schritten, in denen sich zwei Dienste auf einen sicheren Informationsaustausch einigen. Im vorherigen Beispiel für "Terrible Pun of the Day" wurde der häufigste OAuth 2.0-Stream verwendet, der als "Autorisierungscode" -Fluss bezeichnet wird .

Bevor wir uns mit den Details von OAuth befassen, wollen wir uns mit der Bedeutung einiger Begriffe befassen:

  • Ressourceneigentümer :



    Das sind Sie! Sie besitzen Ihre Anmeldeinformationen, Ihre Daten und verwalten alle Aktionen, die mit Ihren Konten ausgeführt werden können.
  • Kunde :



    Eine Anwendung (z. B. der Dienst "Terrible Pun of the Day"), die im Auftrag des Ressourcenbesitzers auf bestimmte Aktionen zugreifen oder diese ausführen möchte.
  • Autorisierungsserver :



    Eine Anwendung, die den Ressourceneigentümer kennt und in der der Ressourceneigentümer bereits ein Konto hat.
  • Ressourcenserver :



    Eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) oder ein Dienst, den ein Client im Auftrag des Ressourcenbesitzers verwenden möchte.
  • URI umleiten :



    Der Link, über den der Authorization Server den Ressourcenbesitzer zu "nach Erteilung der Client- Berechtigung" weiterleitet . Es wird manchmal die Rückruf-URL genannt.
  • Antworttyp :



    Der Informationstyp, den der Client erwartet. Der gebräuchlichste Antworttyp ist der Code, dh der Client erwartet einen Autorisierungscode .
  • Geltungsbereich :



    Dies ist eine detaillierte Beschreibung der Berechtigungen, die der Client benötigt, z. B. den Zugriff auf Daten oder das Ausführen bestimmter Aktionen.
  • Zustimmung :



    Der Autorisierungsserver übernimmt die vom Client angeforderten Bereiche und fragt den Ressourcenbesitzer, ob er bereit ist, dem Client die entsprechenden Berechtigungen zu erteilen.
  • Kunden ID :



    Diese ID wird verwendet, um den Client auf dem Autorisierungsserver zu identifizieren.
  • Kundengeheimnis :



    Dies ist ein Kennwort, das nur dem Client und dem Autorisierungsserver bekannt ist . Sie können vertraulich Informationen austauschen.
  • Autorisierungscode :



    Ein temporärer Kurzzeitcode, den der Client dem Autorisierungsserver im Austausch für ein Zugriffstoken bereitstellt .
  • Zugriffstoken :



    Der Schlüssel, den der Client für die Kommunikation mit dem Ressourcenserver verwendet . Dies ist ein Ausweis oder eine Schlüsselkarte, die dem Kunden die Berechtigung gibt, in Ihrem Namen Daten anzufordern oder Aktionen auf dem Ressourcenserver auszuführen.


Hinweis : Manchmal sind Authorization Server und Resource Server der gleiche Server. In einigen Fällen handelt es sich jedoch möglicherweise um verschiedene Server, die nicht einmal zur gleichen Organisation gehören. Ein Authorization Server kann beispielsweise ein Dienst eines Drittanbieters sein, dem der Resource Server vertraut.

Nachdem wir uns mit den Grundkonzepten von OAuth 2.0 vertraut gemacht haben, kehren wir zu unserem Beispiel zurück und schauen uns genauer an, was im OAuth-Stream passiert.



  1. Sie, der Eigentümer der Ressource , möchten Terrible Pun of the Day ( Kunden ) Zugriff auf Ihre Kontakte gewähren, damit er Einladungen an alle Ihre Freunde senden kann.
  2. Der Client leitet den Browser auf die Seite Authorization Server um und enthält die Client-ID , den Umleitungs-URI , den Antworttyp und einen oder mehrere Bereiche (Berechtigungen), die er in der Anforderung benötigt.
  3. Der Authorization Server überprüft Sie bei Bedarf und fordert Sie auf, einen Benutzernamen und ein Kennwort einzugeben.
  4. Der Authorization Server zeigt ein Einwilligungsformular mit einer Liste aller vom Client angeforderten Bereiche an . Sie stimmen zu oder lehnen ab.
  5. Der Autorisierungsserver leitet Sie mithilfe des Umleitungs-URI zusammen mit dem Autorisierungscode zur Client- Site weiter.
  6. Der Client kommuniziert direkt mit dem Autorisierungsserver (unter Umgehung des Browsers des Ressourcenbesitzers ) und sendet sicher die Client-ID , das Client-Geheimnis und den Autorisierungscode .
  7. Der Authorization Server validiert die Daten und antwortet mit einem Zugriffstoken .
  8. Der Client kann nun mit Access Token eine Anfrage an den Resource Server senden, um eine Kontaktliste zu erhalten.

Kundennummer und Geheimnis


Lange bevor Sie Terrible Pun of the Day Zugriff auf Ihre Kontakte gewährt haben, haben Client und Authorization Server eine funktionierende Beziehung hergestellt. Der Authorization Server hat die Client-ID und das Client-Geheimnis (manchmal auch als App-ID und App-Geheimnis bezeichnet ) generiert und an den Client zur weiteren Interaktion in OAuth gesendet.


"- Hallo! Ich würde gerne mit dir arbeiten! - Ja, keine Frage! Hier sind Ihre Kundennummer und Ihr Geheimnis! “

Der Name weist darauf hin, dass das Client-Geheimnis geheim gehalten werden sollte, damit es nur der Client und der Authorization Server kennen. Mit seiner Hilfe bestätigt der Authorization Server die Wahrheit des Kunden.

Aber das ist noch nicht alles ... Bitte begrüßen Sie OpenID Connect!


OAuth 2.0 ist nur für die Autorisierung vorgesehen , um den Zugriff auf Daten und Funktionen von einer Anwendung zu einer anderen zu ermöglichen. OpenID Connect (OIDC) ist eine dünne Schicht auf OAuth 2.0, die Informationen über den Benutzernamen und das Profil des Benutzers hinzufügt, der beim Konto angemeldet ist. Die Organisation der Anmeldesitzung wird häufig als Authentifizierung bezeichnet , und Informationen über den angemeldeten Benutzer (dh über den Ressourcenbesitzer ) werden als Identität bezeichnet . Wenn der Authorization Server OIDC unterstützt, wird er manchmal als Identitätsanbieter bezeichnet, da er dem Client Informationen zum Ressourcenbesitzer bereitstellt.

Mit OpenID Connect können Sie Szenarien implementieren, in denen eine einzelne Anmeldung in vielen Anwendungen verwendet werden kann. Dieser Ansatz wird auch als Single Sign-On (SSO) bezeichnet. Beispielsweise kann eine Anwendung die SSO-Integration in soziale Netzwerke wie Facebook oder Twitter unterstützen, sodass Benutzer ein Konto verwenden können, das sie bereits besitzen und das sie bevorzugen.



Der OpenID Connect-Ablauf sieht genauso aus wie bei OAuth. Der einzige Unterschied besteht darin, dass in der ersten Anforderung der verwendete Gültigkeitsbereich openid ist und der Client schließlich sowohl das Zugriffstoken als auch das ID-Token erhält.



Genau wie im OAuth-Stream ist das Access Token in OpenID Connect ein Wert, der vom Client nicht verstanden wird. Aus Sicht des Clients stellt das Zugriffstoken eine bestimmte Zeichenfolge dar, die zusammen mit jeder Anforderung an den Ressourcenserver übertragen wird. Diese Zeichenfolge bestimmt, ob das Token gültig ist. ID Token ist ein ganz anderes.

ID Token ist ein JWT


ID-Token ist eine speziell formatierte Zeichenfolge, die als JSON-Web-Token oder JWT bezeichnet wird (manchmal werden JWT-Token als „Jots“ ausgesprochen) . JWT mag für Außenstehende unverständlich erscheinen, aber der Kunde kann verschiedene Informationen aus dem JWT extrahieren, z. B. ID, Benutzername, Anmeldezeit des Kontos, Ablaufdatum des ID-Tokens und Versuche, in das JWT einzugreifen. Die Daten in der Token-ID werden als Anspruch bezeichnet .



Im Fall von OIDC gibt es auch eine Standardmethode, mit der der Client zusätzliche Identitätsinformationen vom Autorisierungsserver anfordern kann, z. B. eine E-Mail-Adresse unter Verwendung des Zugriffstokens .

Erfahren Sie mehr über OAuth und OIDC.


Daher haben wir kurz untersucht, wie OAuth und OIDC funktionieren. Bereit tiefer zu graben? Im Folgenden finden Sie zusätzliche Ressourcen, mit denen Sie mehr über OAuth 2.0 und OpenID Connect erfahren können:


Fühlen Sie sich wie gewohnt frei zu kommentieren. Abonnieren Sie Okta für Twitter und YouTube für Entwickler, um über unsere neuesten Innovationen auf dem Laufenden zu bleiben!

PS vom Übersetzer


Lesen Sie auch in unserem Blog:

Source: https://habr.com/ru/post/de475942/

More articles:


All Articles