Illustriertes Handbuch zu OAuth und OpenID Connect

Hinweis.: In diesem hervorragenden Artikel von Okta werden die Funktionsprinzipien von OAuth und OIDC (OpenID Connect) einfach und anschaulich erklärt. Dieses Wissen ist für Entwickler, Systemadministratoren und sogar für „gewöhnliche Benutzer“ beliebter Webanwendungen nützlich, die wahrscheinlich ebenfalls vertrauliche Daten mit anderen Diensten austauschen.

In der „Steinzeit“ des Internets war es einfach, Informationen zwischen Diensten auszutauschen. Man gab einfach seinen Benutzernamen und Passwort von einem Dienst an einen anderen weiter, damit dieser sich in dein Konto einloggen und alle erforderlichen Informationen abrufen konnte.

„Geben Sie Ihr Bankkonto an.“ – „Wir versprechen, dass mit Ihrem Passwort und Geld alles in Ordnung sein wird. Wirklich ehrlich!“ *kichert*

Schrecklich! Niemand sollte jemals den Nutzer auffordern, seinen Benutzernamen und sein Passwort, seine Anmeldedaten, 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. Es mag absurd erscheinen, aber einige Anwendungen verwenden immer noch solche Praktiken!

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 Fachbegriffe und Jargon, was ihr Verständnis erschwert. Ziel dieses Materials ist es, mithilfe einfacher Illustrationen zu erklären, wie sie funktionieren (Denken Sie, meine Zeichnungen sehen aus wie Kinderkritzeleien? Na und?).

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

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

OAuth 2.0 ist ein Sicherheitsstandard, der es einer Anwendung ermöglicht, die Erlaubnis zu erhalten, auf Informationen einer anderen Anwendung zuzugreifen. Die Schritte zur Erteilung der Erlaubnis [permission] (oder Zustimmung [consent]) werden 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 Passwort preiszugeben. Klasse!

Als Beispiel nehmen wir an, Sie haben eine Website mit dem Titel „Das missratene Wortspiel des Tages“ [Terrible Pun of the Day] und haben sich entschieden, sich dort zu registrieren, um täglich Wortspiele in Form von Textnachrichten auf ihr Handy zu erhalten. Ihnen hat die Seite sehr gefallen, und Sie wollten sie mit allen Bekannten teilen. Denn schreckliche Wortspiele gefallen doch jedem, oder?

„Unglücklicher Wortwitz des Tages: Haben Sie von dem Typ gehört, der seine linke Körperhälfte verloren hat? Jetzt hat er immer recht!“ (Die Übersetzung ist ungefähr, da im Original ein eigenes Wortspiel enthalten ist – Anmerkung des Übersetzers.)

Es ist klar, dass es keine Option ist, jedem einzelnen Kontakt zu schreiben. Und wenn Sie auch nur ein bisschen so sind wie ich, werden Sie alles tun, um Überstunden zu vermeiden. Glücklicherweise kann Terrible Pun of the Day selbst alle Ihre Freunde einladen! Dafür müssen Sie nur den Zugriff auf die E-Mail-Kontakte öffnen – die Seite wird die Einladungen automatisch versenden (OAuth ist großartig)!

„Alle lieben Wortspiele! – Haben Sie sich bereits angemeldet? – Möchten Sie der Website Terrible Pun of the Day Zugriff auf Ihre Kontaktliste gewähren? – Vielen Dank! Ab sofort senden wir täglich Erinnerungen an alle, die Sie kennen, bis ans Ende der Zeit! Sie sind der beste Freund!“

1. Wählen Sie Ihren E-Mail-Dienst.
2. Falls nötig, besuchen Sie die Website Ihres E-Mail-Dienstes und loggen Sie sich in Ihr Konto ein.
3. Erlauben Sie der Website Terrible Pun of the Day den Zugriff auf Ihre Kontakte.
4. Kehrt zur Website 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 länger mit Terrible Pun of the Day teilen möchten, können Sie zur Mail-Seite gehen und die Website mit den Wortspielen aus der Liste der autorisierten Anwendungen entfernen.

OAuth-Stream

Wir haben gerade den durchlaufen, was normalerweise als Flow [flow] OAuth bezeichnet. In unserem Beispiel besteht dieser Flow aus sichtbaren Schritten sowie aus mehreren unsichtbaren Schritten, in denen zwei Dienste eine sichere Vereinbarung über den Austausch von Informationen treffen. Im vorherigen Beispiel mit Terrible Pun of the Day wird der am häufigsten verwendete OAuth 2.0-Flow verwendet, bekannt als Flow «mit Autorisierungscode» [„authorization code“ flow].

Bevor wir uns mit den Details der Funktionsweise von OAuth befassen, lassen Sie uns über die Bedeutung einiger Begriffe sprechen:

• Ressourcenbesitzer:

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

• Client:

  
  
  Eine Anwendung (zum Beispiel der Dienst Terrible Pun of the Day), die Zugriff verlangen oder bestimmte Aktionen im Namen von Ressourcenbesitzerdurchführen möchte.

• Autorisierungsserver:

  
  
  Eine Anwendung, die bereits weiß Ressourcenbesitzerund bei der bereits ein Konto besteht. RessourcenbesitzerRessourcenserver

• Die Programmierschnittstelle (API) oder der Dienst, den:

  
  
  im Namen von nutzen möchte. Client Redirect-URI Ressourcenbesitzerdurchführen möchte.

• Der Link, auf den:

  
  
  nach Gewährung der Berechtigung umleiten wird. Autorisierungsserver Manchmal auch als "Rückruf-URL" bezeichnet. RessourcenbesitzerAntworttyp ClientDie Art von Informationen, die erwartet wird.

• Der gängigste:

  
  
  ist der Code, das heißt, Clienter wird erwartet zu erhalten. Der gängigsteAutorisierungscode Client Bereich Eine detaillierte Beschreibung der Berechtigungen, die erforderlich sind,.

• wie der Zugriff auf Daten oder das Durchführen bestimmter Aktionen.:

  
  
  Zustimmung Clienterfasst

• Die angeforderten Bereiche von:

  
  
  Autorisierungsserver und fragt, ob bereit ist, die entsprechenden Berechtigungen zur Verfügung zu stellen.Client-ID ClientDiese ID wird verwendet, um Ressourcenbesitzerbei Clientzu identifizieren.

• Client-Geheimnis:

  
  
  Dies ist ein Passwort, das nur Clientkennt und Autorisierungsserververtraulich Informationen austauschen kann.

• Ein temporärer Code mit einer kurzen Gültigkeitsdauer, den:

  
  
  im Austausch gegen ClientAccess-Token erhalten kann. AutorisierungsserverEr ermöglicht es ihnen, Informationen vertraulich auszutauschen.

• Eine detaillierte Beschreibung der Berechtigungen, die erforderlich sind,:

  
  
  Ein temporärer Code mit kurzer Gültigkeitsdauer, der Client bietet Autorisierungsserverim Austausch gegen Access Token.

• Access Token:

  
  
  Der Schlüssel, den der Kunde verwenden wird, um sich mit Die Programmierschnittstelle (API) oder der Dienst, denzu verbinden. Eine Art Ausweis oder Schlüsselkarte, die Clientdem Zugang von Die Programmierschnittstelle (API) oder der Dienst, denzur Anfrage von Daten oder zur Durchführung von Aktionen in

Hinweisim Namen von Ihnen gewährt.

: Manchmal sind der Authorization Server und der Resource Server derselbe Server. In einigen Fällen können es jedoch unterschiedliche Server sein, die nicht einmal zu derselben Organisation gehören. Zum Beispiel kann der Authorization Server ein Drittanbieterdienst sein, dem der Resource Server vertraut.

1. Jetzt, wo wir die grundlegenden Konzepte von OAuth 2.0 kennen, lass uns zu unserem Beispiel zurückkehren und im Detail betrachten, was im OAuth-Fluss passiert. RessourcenbesitzerSieClientmöchten dem Dienst Terrible Pun of the Day (
2. Client ) Zugriff auf Ihre Kontakte gewähren, damit er Einladungen an all Ihre Freunde senden kann. Autorisierungsserverleitet den Browser auf die Seite von Client-Geheimnis, Der Link, auf den, Der gängigste weiter und fügt in die Anfrage bereit ist, die entsprechenden Berechtigungen zur Verfügung zu stellen. und eine oder mehrere
3. Autorisierungsserver (Berechtigungen), die benötigt werden.
4. Autorisierungsserver überprüft Sie und fragt gegebenenfalls nach Ihrem Benutzernamen und Passwort. Die angeforderten Bereiche von zeigt ein Formular bereit ist, die entsprechenden Berechtigungen zur Verfügung zu stellen.(Bestätigung) mit einer Liste aller Client, die von
5. Autorisierungsserver angefordert werden. Sie stimmen zu oder lehnen ab. Clientleitet Sie zurück zur Website von Der Link, auf den , indem es Eine detaillierte Beschreibung der Berechtigungen, die erforderlich sind, mit dem
6. Client Verbindung aufnimmt. Autorisierungsserverüber den Browser hinweg Ressourcenbesitzerund sicher sendet Client-Geheimnis, Ein temporärer Code mit einer kurzen Gültigkeitsdauer, den und Eine detaillierte Beschreibung der Berechtigungen, die erforderlich sind,.
7. Autorisierungsserver die Daten überprüft und mit Access Tokeneinem Token (Zugriffstoken).
8. Jetzt Client kann genutzt werden Access Token um eine Anfrage zu senden, Die Programmierschnittstelle (API) oder der Dienst, den um eine Liste von Kontakten zu erhalten.

Client-ID und Secret

Lange bevor Sie Terrible Pun of the Day den Zugriff auf die Kontakte erlaubt haben, haben Client und Authorization Server eine Arbeitsbeziehung aufgebaut. Der Authorization Server generierte die Client-ID und das Client-Secret (manchmal auch App-ID und App-Secret) und schickte sie an den Client für die weitere Interaktion im Rahmen von OAuth.

„— Hallo! Ich möchte mit dir arbeiten! — Kein Problem! Hier sind deine Client-ID und dein Secret!“

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

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

OAuth 2.0 wurde ausschließlich für Autorisierung entwickelt — um den Zugriff auf Daten und Funktionen von einer Anwendung zur anderen zu ermöglichen. OpenID Connect (OIDC) ist eine dünne Schicht über OAuth 2.0, die Informationen über die Anmeldung und das Profil des Benutzers hinzufügt, der sich in das Konto eingeloggt hat. Die Organisation von Login-Sitzungen wird oft als Authentifizierung [authentication], und Informationen über den Benutzer, der sich im System angemeldet hat (d.h. über Ressourcenbesitzer‘e), — personenzugänglichen Daten [identity]. Wenn der Authorization Server OIDC unterstützt, wird er manchmal als Anbieter von persönlichen Daten [identity provider]bezeichnet, da er Client‘e Informationen über Ressourcenbesitzervertraulich Informationen austauschen kann.

OpenID Connect ermöglicht die Implementierung von Szenarien, in denen eine einzige Anmeldung für mehrere Anwendungen verwendet werden kann – dieser Ansatz ist auch bekannt als Single Sign-On (SSO). Zum Beispiel kann eine Anwendung die SSO-Integration 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 Flow (Ablauf) von OpenID Connect sieht ähnlich aus wie bei OAuth. Der einzige Unterschied besteht darin, dass im Hauptanfrage der spezifische Scope – openid, — verwendet wird, während Client schließlich sowohl als Access Token, als auch ID Token.

geltend ist. Wie im OAuth-Fluss? Access Token in OpenID Connect – ist das ein Wert, der für Client‘e nicht verständlich ist. Aus der Sicht von Client‘a Access Token stellt es eine Zeichenfolge dar, die bei jeder Anfrage an Die Programmierschnittstelle (API) oder der Dienst, den‘a übermittelt wird, und dieser überprüft, ob der Token gültig ist. ID Token stellt etwas ganz anderes dar.

ID Token ist ein JWT

ID Token — ist eine speziell formatierte Zeichenkette, die als JSON Web Token oder JWT bekannt ist (manchmal werden JWTs als „jots“ ausgesprochen). Für Außenstehende kann JWT wie ein unverstehbares Kauderwelsch erscheinen, jedoch Client kann man aus JWT verschiedene Informationen extrahieren, wie z. B. ID, Benutzernamen, Anmeldezeitpunkt, Ablaufdatum ID Tokenund mögliche Versuche, in das JWT einzugreifen. Die Daten innerhalb des ID Tokenwerden als Ansprüche [claims].

In Bezug auf OIDC gibt es auch einen standardisierten Weg, über den Client zusätzliche Informationen zur Identität [identity] ab Autorisierungsserverabgerufen werden können, wie z. B. die E-Mail-Adresse, wobei Access Token.

weitere Informationen zu OAuth und OIDC

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

• Was zum Teufel ist OAuth?
• Niemand interessiert sich für OAuth oder OpenID Connect
• Implementieren Sie den OAuth 2.0 Autorisierungscode mit PKCE-Flow
• Was ist der OAuth 2.0 Grant Type?
• 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 Entwicklungen informiert zu bleiben, abonnieren Sie Twitter und YouTube das Entwicklerprogramm von Okta!

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

• «Sicherheits-Alphabet in Kubernetes: Authentifizierung, Autorisierung, Audit»;
• «Benutzer und RBAC-Autorisierung in Kubernetes»;
• «33+ Werkzeuge zur Sicherheit von Kubernetes»;
• «Sicherheit für Docker-Container».

Quelle: habr.com