Illustriertes Handbuch zu OAuth und OpenID Connect

Anmerkung des Übersetzers.: In diesem hervorragenden Material von Okta werden die Funktionsprinzipien von OAuth und OIDC (OpenID Connect) einfach und anschaulich erläutert. Dieses Wissen ist für Entwickler, Systemadministratoren und sogar "normale Benutzer" beliebter Webanwendungen, die wahrscheinlich ebenfalls vertrauliche Daten mit anderen Diensten austauschen, nützlich.

Im "Steinzeitalter" des Internets war es einfach, Informationen zwischen Diensten auszutauschen. Man gab einfach seinen Login und sein Passwort von einem Dienst an einen anderen weiter, damit dieser in das eigene Konto einloggen und alle benötigten Informationen abrufen konnte.

"Geben Sie Ihr Bankkonto an." – "Wir versprechen, dass mit Passwort und Geld alles in Ordnung sein wird. Wirklich ganz ehrlich!" *hi hi*

Schrecklich! Niemand sollte jemals von einem Benutzer verlangen, sein Login und Passwort, seine Zugangsdaten, mit einem anderen Dienst zu teilen. Es gibt keine Garantie, dass die Organisation hinter diesem Dienst die Daten sicher speichert und nicht mehr persönliche Informationen sammelt, als nötig ist. Das mag verrückt erscheinen, aber einige Anwendungen praktizieren diese Methode nach wie vor!

Heute gibt es einen einheitlichen Standard, der es einem Dienst ermöglicht, sicher auf die Daten eines anderen zuzugreifen. Leider verwenden solche Standards eine Menge Jargon und Fachbegriffe, was das Verständnis erschwert. Ziel dieses Materials ist es, mit einfachen Illustrationen zu erklären, wie sie funktionieren (Denkst du, meine Zeichnungen sind wie Kinderkritzeleien? Na und!).

Übrigens ist dieses Handbuch auch im Videoformat verfügbar:

Meine Damen und Herren, präsentieren Sie: OAuth 2.0

OAuth 2.0 ist ein Sicherheitsstandard, der es einer Anwendung ermöglicht, die Erlaubnis zum Zugriff auf Informationen in einer anderen Anwendung zu erhalten. Der Vorgang zur Erteilung der Erlaubnis [permission] (oder Zustimmung [consent]) wird oft als Autorisierung [authorization] oder sogar delegierte Autorisierung [delegated authorization]. Mit diesem Standard erlauben Sie einer Anwendung, Daten abzurufen oder Funktionen einer anderen Anwendung in Ihrem Namen zu nutzen, ohne ihr Ihr Passwort mitzuteilen. Cool!

Als Beispiel nehmen wir an, Sie haben eine Website mit dem Titel „Der missratene Wortwitz des Tages“ [Terrible Pun of the Day] Und Sie haben beschlossen, sich dort zu registrieren, um täglich Wortspiele in Form von Textnachrichten auf Ihr Telefon zu erhalten. Ihnen hat die Webseite sehr gut gefallen, und Sie haben beschlossen, sie mit all Ihren Bekannten zu teilen. Schließlich mögen alle schrecklichen Wortspiele, nicht wahr?

„Missratener Kalauer des Tages: Haben Sie von dem Typen gehört, der seine linke Körperhälfte verloren hat? Jetzt hat er immer recht!“ (Übersetzung ungefähr, da im Original ein Wortspiel ist – Anm. der Übers.)

Es ist klar, dass es keine Option ist, jedem Einzelnen aus der Kontaktliste zu schreiben. Und wenn Sie auch nur ein kleines bisschen so sind wie ich, werden Sie alles tun, um unnötige Arbeit zu vermeiden. Glücklicherweise kann Terrible Pun of the Day alle Ihre Freunde selbst einladen! Dazu müssen Sie ihm lediglich Zugriff auf die E-Mail-Kontakte gewähren – die Webseite sendet ihnen automatisch Einladungen (OAuth regelt das)!

„Alle lieben Wortspiele! – Schon eingeloggt? – Möchten Sie der Webseite Terrible Pun of the Day Zugriff auf die Kontaktliste gewähren? – Danke! Jetzt werden wir jedem von Ihren Freunden bis in alle Ewigkeit tägliche Erinnerungen senden! Sie sind der beste Freund!“

1. Wählen Sie Ihren E-Mail-Dienst.
2. Gehen Sie bei Bedarf zur Webseite des E-Mail-Anbieters und melden Sie sich in Ihrem Konto an.
3. Geben Sie der Webseite Terrible Pun of the Day die Erlaubnis, auf Ihre Kontakte zuzugreifen.
4. Kehren Sie zur Webseite Terrible Pun of the Day zurück.

Falls Sie Ihre Meinung ändern, bieten Anwendungen, die OAuth verwenden, auch eine Möglichkeit, den Zugriff zu widerrufen. Wenn Sie entscheiden, dass Sie Ihre Kontakte nicht mehr mit Terrible Pun of the Day teilen möchten, können Sie zur Webseite des E-Mail-Anbieters gehen und die Webseite mit den Wortspielen aus der Liste der autorisierten Anwendungen entfernen.

OAuth-Flow

Gerade haben wir das durchlaufen, was normalerweise als Flow [flow] OAuth bekannt ist. In unserem Beispiel besteht dieser Flow aus sichtbaren Schritten sowie einigen unsichtbaren Schritten, in denen zwei Dienste sich über den sicheren Austausch von Informationen einigen. Im vorherigen Beispiel mit Terrible Pun of the Day wird der am weitesten verbreitete OAuth 2.0-Flow verwendet, der als „Authorization Code Flow“ bekannt ist. [„authorization code“ flow].

Bevor wir in die Einzelheiten des OAuth-Betriebs eintauchen, lassen Sie uns über die Bedeutung einiger Begriffe sprechen:

• Resource Owner:

  
  
  Das sind Sie! Sie besitzen Ihre Anmeldeinformationen, Ihre Daten und steuern alle Aktionen, die mit Ihren Konten durchgeführt werden können.

• Client:

  
  
  Eine Anwendung (z. B. der Dienst Terrible Pun of the Day), die Zugriff erhalten oder bestimmte Aktionen im Namen von Resource Owner‘a.

• Autorisierungsserver:

  
  
  Eine Anwendung, die weiß Resource Owner‘a und bei der Resource Owner‘a bereits ein Konto hat.

• Ressourcenserver:

  
  
  Programmierschnittstelle (API) oder Dienst, den Client im Namen von nutzen möchte Resource Owner‘a.

• Weiterleitungs-URI:

  
  
  Ein Link, über den Autorisierungsserver weiterleitet Resource Owner‘a nach der Erteilung der Genehmigung Client‘u. Manchmal wird es auch als „Callback-URL“ bezeichnet.

• Antworttyp:

  
  
  Der Typ der Informationen, die erwartet werden, dass sie erhalten werden Client. Der häufigste Antworttyp‘a ist der Code, das heißt Client beabsichtigt zu erhalten Autorisierungscode.

• Bereich:

  
  
  Dies ist eine detaillierte Beschreibung der Berechtigungen, die erforderlich sind Client‘u, wie z. B. der Zugriff auf Daten oder die Ausführung bestimmter Aktionen.

• Zustimmung:

  
  
  Autorisierungsserver nimmt Bereiche, die angefordert werden Client‘a, und fragt Resource Owner‘a, ob er bereit ist, Client‘u die entsprechenden Berechtigungen zu geben.

• Client-ID:

  
  
  Diese ID wird verwendet, um Client‘a auf Autorisierungsserver‘e zu identifizieren.

• Client-Geheimnis:

  
  
  Dies ist ein Passwort, das nur Client‘u und Autorisierungsserver‘u bekannt ist. Es ermöglicht ihnen, Informationen vertraulich auszutauschen.

• Autorisierungscode:

  
  
  Ein temporärer Code mit einer kurzen Gültigkeitsdauer, den Client ein Framework zur Erstellung von Komponenten, die Programme sind, die in ihrer eigenen Sandbox ausgeführt werden und über IPC mit anderen Komponenten interagieren können. Autorisierungsserver‘u im Austausch gegen Zugangstoken.

• Zugangstoken:

  
  
  Ein Schlüssel, den der Client verwenden wird, um sich mit Ressourcenserver‘o zu verbinden. Eine Art Ausweis oder Schlüsselkarte, die Client‘u die Erlaubnis gibt, Daten abzufragen oder Aktionen auf Ressourcenserver‘e in Ihrem Namen auszuführen.

Hinweis: Manchmal sind der Autorisierungsserver und der Ressourcenserver derselbe Server. In einigen Fällen können es jedoch verschiedene Server sein, die sogar nicht zur selben Organisation gehören. Beispielsweise könnte der Autorisierungsserver ein Drittanbieterdienst sein, dem der Ressourcenserver vertraut.

Nun, da wir mit den grundlegenden Begriffen von OAuth 2.0 vertraut sind, lassen Sie uns zu unserem Beispiel zurückkehren und genauer betrachten, was in dem OAuth-Thread passiert.

1. Sie, Resource Owner, möchten dem Dienst Terrible Pun of the Day (Client‘u) Zugriff auf Ihre Kontakte geben, damit dieser Einladungen an Ihre Freunde versenden kann.
2. Client leitet den Browser zur Seite von Autorisierungsserver‘a um und schließt im Antrag Client-ID, Weiterleitungs-URI, Antworttyp und eines oder mehrere Bereiche (Berechtigungen) ein, die er benötigt.
3. Autorisierungsserver überprüft Sie, indem er, falls erforderlich, nach Anmeldedaten fragt.
4. Autorisierungsserver zeigt ein Formular Zustimmung (Bestätigung) mit einer Liste aller Bereiche, die von Client‘a angefordert werden. Sie stimmen zu oder lehnen ab.
5. Autorisierungsserver leitet Sie auf die Website von Client‘a um, unter Verwendung von Weiterleitungs-URI zusammen mit Autorisierungscode (Autorisierungscode).
6. Client stellt direkt eine Verbindung her mit Autorisierungsserver‘o (um den Browser zu umgehen. Resource Ownerund sicher sendet Client-ID, Client-Geheimnis und Autorisierungscode.
7. Autorisierungsserver die Daten überprüft und mit Zugangstokeneinem (Zugriffstoken) antwortet.
8. Jetzt Client kann verwenden Zugangstoken um eine Anfrage zu senden, um Ressourcenserver eine Kontaktliste zu erhalten.

Client-ID und Secret

Lange bevor Sie Terrible Pun of the Day den Zugriff auf Ihre Kontakte gestattet haben, haben Client und Autorisierungsserver eine Arbeitsbeziehung etabliert. Der Autorisierungsserver generierte die Client-ID und das Client-Secret (manchmal auch genannt App-ID und App-Secret) und sandte sie an den Client zur weiteren Interaktion im Rahmen von OAuth.

„— Hi! Ich würde gerne mit dir arbeiten! — Kein Problem! Hier sind deine Client-ID und das Secret!“

Der Name deutet darauf hin, dass das Client-Secret geheim gehalten werden sollte, damit nur der Client und der Autorisierungsserver es kennen. Schließlich bestätigt der Autorisierungsserver mit dessen Hilfe die Echtheit des Clients.

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

OAuth 2.0 wurde nur für Autorisierung entwickelt – um den Zugang zu Daten und Funktionen von einer Anwendung zu einer anderen zu ermöglichen. OpenID Connect (OIDC) ist eine Schicht über OAuth 2.0, die Informationen über die Anmeldung und das Benutzerprofil des angemeldeten Kontos hinzufügt. Die Verwaltung der Anmeldesitzung wird oft als Authentifizierung [authentication]bezeichnet, während die Informationen über den angemeldeten Benutzer (d.h. über Resource Ownerdie Identität), personenbezogene Daten [identity]. Wenn der Autorisierungsserver OIDC unterstützt, wird er manchmal als Identitätsanbieter [identity provider]bezeichnet, da er Informationen über Clientdie Identität bereitstellt. Resource Owner‘e zu identifizieren.

OpenID Connect ermöglicht Szenarien, in denen sich ein Benutzer mit nur einer Anmeldung in mehreren Anwendungen anmelden kann – dieser Ansatz ist auch bekannt als Single Sign-On (SSO). Zum Beispiel kann eine Anwendung SSO-Integrationen mit sozialen Netzwerken wie Facebook oder Twitter unterstützen, sodass Benutzer ein Konto verwenden können, das sie bereits haben und das sie bevorzugen.

Der OpenID Connect-Flow sieht ähnlich aus wie bei OAuth. Der einzige Unterschied besteht darin, dass im ursprünglichen Anfrage der verwendete spezifische Scope openid, und Client er letztendlich sowohl Zugangstoken, als auch ID-Token.

So wie im OAuth-Flow ist Zugangstoken im OpenID Connect ein Wert, der für Clientden Server nicht verständlich ist. Aus der Perspektive Clientdes Authentifizierungsservers Zugangstoken stellt er eine Zeichenfolge dar, die zusammen mit jeder Anfrage an Ressourcenserverden Server übermittelt wird, der dann prüft, ob der Token gültig ist. ID-Token stellt etwas völlig anderes dar.

Das ID-Token ist ein JWT

ID-Token — eine speziell formatierte Zeichenfolge, die als JSON Web Token oder JWT bekannt ist. (Manchmal wird JWT als „jots“ ausgesprochen). Für Außenstehende kann JWT wie ein unverständliches Kauderwelsch erscheinen, jedoch Client kann aus JWT verschiedene Informationen wie ID, Benutzername, Anmeldezeit, Ablaufzeit ID-Tokenund mögliche Versuche zur Manipulation von JWT extrahiert werden. Die Daten innerhalb ID-Tokenwerden als Claims [claims].

Im Falle von OIDC gibt es auch einen standardisierten Weg, wie man Client zusätzliche Informationen zur Identität [identity] ab Autorisierungsserveranfordern kann, wie zum Beispiel die E-Mail-Adresse, unter Verwendung von Zugangstoken.

Zusätzliche Informationen zu OAuth und OIDC

Also, wir haben die Grundprinzipien von OAuth und OIDC kurz behandelt. Bereit für tiefere Einblicke? Hier sind zusätzliche Ressourcen, die helfen, mehr über OAuth 2.0 und OpenID Connect zu erfahren:

• Was ist OAuth?
• Niemand interessiert sich für OAuth oder OpenID Connect
• Implementierung des OAuth 2.0 Autorisierungscodes mit PKCE Fluss
• Was ist der OAuth 2.0 Grant-Typ?
• OAuth 2.0 von der Befehlszeile aus
• Erstellen Sie eine sichere Node.js-App mit SQL Server

Wie gewohnt, zögern Sie nicht, Kommentare abzugeben. Um über unsere neuesten Angebote informiert zu bleiben, abonnieren Sie Twitter und YouTube das Entwicklerprogramm von Okta!

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

• «Sicherheitsgrundlagen in Kubernetes: Authentifizierung, Autorisierung, Audit»;
• «Benutzer und RBAC-Authorization in Kubernetes»;
• «33+ Tools für die Sicherheit von Kubernetes»;
• «Sicherheit für Docker-Container».

Quelle: habr.com