Notiz. übersetzen: Dieser großartige Artikel von Okta erklärt auf einfache und klare Weise, wie OAuth und OIDC (OpenID Connect) funktionieren. Dieses Wissen wird für Entwickler, Systemadministratoren und sogar „normale Benutzer“ beliebter Webanwendungen nützlich sein, die höchstwahrscheinlich auch vertrauliche Daten mit anderen Diensten austauschen.
In der Steinzeit des Internets war der Informationsaustausch zwischen Diensten einfach. Sie gaben einfach Ihren Benutzernamen und Ihr Passwort von einem Dienst an einen anderen weiter, sodass er sich in Ihr Konto einloggen und alle benötigten Informationen erhalten konnte.
„Geben Sie mir Ihr Bankkonto.“ „Wir versprechen, dass mit dem Passwort und dem Geld alles gut wird. Das ist ehrlich, ehrlich!“ *hihihi*
Grusel! Niemand sollte jemals von einem Benutzer verlangen, dass er einen Benutzernamen und ein Passwort teilt. Referenzen, mit einem anderen Dienst. Es gibt keine Garantie dafür, dass die Organisation hinter diesem Dienst die Daten sicher verwahrt und nicht mehr personenbezogene Daten als nötig erfasst. Es mag verrückt klingen, aber einige Apps verwenden diese Vorgehensweise immer noch!
Heute gibt es einen einzigen Standard, der es einem Dienst ermöglicht, die Daten eines anderen sicher zu nutzen. Leider verwenden solche Standards eine Menge Fachjargon und Begriffe, was ihr Verständnis erschwert. Der Zweck dieses Materials besteht darin, anhand einfacher Illustrationen zu erklären, wie sie funktionieren (Glauben Sie, dass meine Zeichnungen den Klecksen von Kindern ähneln? Na ja!).
Diesen Ratgeber gibt es übrigens auch im Videoformat:
Meine Damen und Herren, willkommen: OAuth 2.0
ist ein Sicherheitsstandard, der es einer Anwendung ermöglicht, die Berechtigung zum Zugriff auf Informationen in einer anderen Anwendung zu erhalten. Ablauf der Schritte zur Erteilung einer Genehmigung [Erlaubnis] (oder Zustimmung [Zustimmung]) rufen oft an Genehmigung [Genehmigung] oder delegierte Autorisierung [delegierte Autorisierung]. Mit diesem Standard gestatten Sie einer Anwendung, in Ihrem Namen Daten zu lesen oder die Funktionen einer anderen Anwendung zu nutzen, ohne ihr Ihr Passwort mitzuteilen. Klasse!
Nehmen wir als Beispiel an, Sie entdecken eine Website mit dem Titel „Unlucky Pun of the Day“. [Schreckliches Wortspiel des Tages] und beschloss, sich dort zu registrieren, um täglich Wortspiele in Form von Textnachrichten auf dem Telefon zu erhalten. Die Seite hat Ihnen wirklich gut gefallen und Sie haben beschlossen, sie mit all Ihren Freunden zu teilen. Schließlich mag doch jeder gruselige Wortspiele, oder?
„Unglückliches Wortspiel des Tages: Haben Sie von dem Mann gehört, der die linke Körperhälfte verloren hat? Jetzt hat er immer Recht!“ (ungefähre Übersetzung, da das Original ein eigenes Wortspiel hat – ungefähre Übersetzung.)
Es ist klar, dass es keine Option ist, jede Person aus der Kontaktliste anzuschreiben. Und wenn Sie auch nur ein bisschen wie ich sind, 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 lediglich den Zugriff auf die E-Mails Ihrer Kontakte öffnen – die Site selbst sendet ihnen Einladungen (OAuth-Regeln)!
„Jeder liebt Wortspiele! - Bereits angemeldet? „Möchten Sie der Website „Terrible Pun of the Day“ den Zugriff auf Ihre Kontaktliste erlauben? - Danke! Von nun an senden wir bis zum Ende der Zeit jeden Tag Erinnerungen an alle, die Sie kennen! Sie sind der beste Freund!"
- Wählen Sie Ihren E-Mail-Dienst.
- Gehen Sie bei Bedarf zur E-Mail-Site und melden Sie sich bei Ihrem Konto an.
- Erteilen Sie Terrible Pun of the Day die Erlaubnis, auf Ihre Kontakte zuzugreifen.
- Kehren Sie 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. Sobald Sie entscheiden, dass Sie keine Kontakte mehr mit Terrible Pun of the Day teilen möchten, können Sie zur E-Mail-Site gehen und die Pun-Site aus der Liste der autorisierten Anwendungen entfernen.
OAuth-Flow
Wir haben gerade das durchlaufen, was normalerweise so genannt wird Fluss [Fluss] OAuth. In unserem Beispiel besteht dieser Ablauf aus sichtbaren Schritten sowie mehreren unsichtbaren Schritten, in denen sich zwei Dienste auf einen sicheren Informationsaustausch einigen. Das vorherige Beispiel „Terrible Pun of the Day“ verwendet den gebräuchlichsten OAuth 2.0-Flow, den sogenannten „Autorisierungscode“-Flow. [Ablauf „Autorisierungscode“].
Bevor wir näher auf die Funktionsweise von OAuth eingehen, sprechen wir zunächst über die Bedeutung einiger Begriffe:
- Ressourcenbesitzer:
Das sind Sie! Sie besitzen Ihre Anmeldeinformationen und Daten und kontrollieren alle Aktivitäten, die auf Ihren Konten ausgeführt werden können. - Kunden:
Eine Anwendung (z. B. der Dienst „Terrible Pun of the Day“), die im Namen von auf bestimmte Aktionen zugreifen oder diese ausführen möchte Ressourcenbesitzer'. - Autorisierungsserver:
Die Anwendung, die es weiß Ressourcenbesitzer'a und in dem u Ressourcenbesitzer'a haben bereits ein Konto. - Ressourcenserver:
Anwendungsprogrammierschnittstelle (API) oder Dienst Kunden im Namen verwenden möchte Ressourcenbesitzer'. - Umleitungs-URI:
Der Link, der Autorisierungsserver wird umleiten Ressourcenbesitzer'und nach Erteilung der Erlaubnis Kunden'bei. Sie wird manchmal als „Rückruf-URL“ bezeichnet. - Antworttyp:
Die Art der Informationen, die voraussichtlich empfangen werden Kunden. Das Üblichste Antworttyp„Ohm ist der Code, das heißt.“ Kunden erwartet zu erhalten Autorisierungscode. - Geltungsbereich:
Dies ist eine detaillierte Beschreibung der erforderlichen Berechtigungen KundenB. auf Daten zugreifen oder bestimmte Aktionen ausführen. - Zustimmung:
Autorisierungsserver dauert Scopesangefordert Kunden'om, und fragt Ressourcenbesitzer'a, ist er bereit zu liefern Kunden'über die entsprechenden Berechtigungen verfügen. - Kunden-ID:
Diese ID dient der Identifizierung Kunden'ein auf Autorisierungsserver'e. - Kundengeheimnis:
Dies ist das Passwort, das nur bekannt ist Kunden'du und Autorisierungsserver'bei. Es ermöglicht ihnen, Informationen privat auszutauschen. - Autorisierungscode:
Temporärer Code mit kurzer Gültigkeitsdauer, der Kunden bietet Autorisierungsserver'y im Austausch für Zugangstoken. - Zugangstoken:
Der Schlüssel, mit dem der Client kommuniziert Ressourcenserver'om. Eine Art Abzeichen oder Schlüsselkarte, die Folgendes bereitstellt Kunden'haben die Berechtigung, Daten anzufordern oder Aktionen durchzuführen RessourcenserverIch bin in Ihrem Namen.
Beachten: Manchmal sind Autorisierungsserver und Ressourcenserver derselbe Server. In einigen Fällen kann es sich jedoch um unterschiedliche Server handeln, auch wenn diese nicht zur selben Organisation gehören. Der Autorisierungsserver könnte beispielsweise ein Drittanbieterdienst sein, dem der Ressourcenserver vertraut.
Nachdem wir nun die Kernkonzepte von OAuth 2.0 behandelt haben, kehren wir zu unserem Beispiel zurück und schauen uns genauer an, was im OAuth-Fluss passiert.
- Sie Ressourcenbesitzer, möchten Sie den Service „Terrible Pun of the Day“ anbieten (Kundeny) Zugriff auf Ihre Kontakte, damit diese Einladungen an alle Ihre Freunde senden können.
- Kunden Leitet den Browser auf die Seite weiter Autorisierungsserver'a und in die Abfrage einbeziehen Kunden-ID, Umleitungs-URI, Antworttyp und einer oder mehrere Scopes (Berechtigungen), die es benötigt.
- Autorisierungsserver verifiziert Sie und fragt bei Bedarf nach einem Benutzernamen und einem Passwort.
- Autorisierungsserver zeigt ein Formular an Zustimmung (Bestätigungen) mit einer Liste aller Scopesangefordert Kunden'om. Sie stimmen zu oder lehnen ab.
- Autorisierungsserver leitet Sie zur Website weiter Kunden'a, mit Umleitungs-URI mit Autorisierungscode (Autorisierungscode).
- Kunden kommuniziert direkt mit Autorisierungsserver'ohm (unter Umgehung des Browsers Ressourcenbesitzer'a) und sicher sendet Kunden-ID, Kundengeheimnis и Autorisierungscode.
- Autorisierungsserver prüft die Daten und antwortet mit Zugangstoken'om (Zugriffstoken).
- Jetzt Kunden Kann benutzen Zugangstoken um eine Anfrage zu senden Ressourcenserver um eine Liste der Kontakte zu erhalten.
Client-ID und Geheimnis
Lange bevor Sie Terrible Pun of the Day Zugriff auf Ihre Kontakte gewährten, hatten der Client und der Autorisierungsserver eine funktionierende Beziehung aufgebaut. Der Autorisierungsserver generierte die Client-ID und das Client-Geheimnis (manchmal auch „ App ID и App Geheimnis) und schickte sie zur weiteren Interaktion innerhalb von OAuth an den Client.
"- Hallo! Ich würde gerne mit Ihnen zusammenarbeiten! - Klar, kein Problem! Hier sind Ihre Kunden-ID und Ihr Geheimnis!“
Der Name impliziert, dass das Client-Geheimnis geheim gehalten werden muss, sodass nur der Client und der Autorisierungsserver es kennen. Schließlich bestätigt der Autorisierungsserver mit seiner Hilfe die Wahrheit des Clients.
Aber das ist noch nicht alles ... Bitte begrüßen Sie OpenID Connect!
OAuth 2.0 ist nur für konzipiert Genehmigung - um den Zugriff auf Daten und Funktionen von einer Anwendung zu einer anderen zu ermöglichen. (OIDC) ist eine dünne Schicht auf OAuth 2.0, die die Anmelde- und Profildetails des Benutzers hinzufügt, der im Konto angemeldet ist. Die Organisation einer Login-Sitzung wird oft als bezeichnet Authentifizierung [Authentifizierung], und Informationen über den im System angemeldeten Benutzer (d. h. über Ressourcenbesitzer'e), – persönliche Daten [Identität]. Wenn der Autorisierungsserver OIDC unterstützt, wird er manchmal als bezeichnet Anbieter personenbezogener Daten [Identitätsanbieter]weil es sorgt Kunden'Informationen haben über Ressourcenbesitzer'e.
Mit OpenID Connect können Sie Szenarien implementieren, in denen ein einziger Login in mehreren Anwendungen verwendet werden kann – dieser Ansatz wird auch als „OpenID Connect“ bezeichnet Einmalige Anmeldung (SSO). Beispielsweise 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 lieber verwenden.
Der Flow (Flow) von OpenID Connect sieht genauso aus wie bei OAuth. Der einzige Unterschied besteht darin, dass in der primären Anfrage der spezifische Bereich verwendet wird openid, - A Kunden irgendwann wird es so ZugangstokenUnd ID-Token.
Genau wie im OAuth-Flow, Zugangstoken In OpenID Connect ist dies ein Wert, der nicht klar ist Kunden'bei. In Hinsicht auf Kunden' Zugangstoken stellt eine Zeichenfolge dar, die bei jeder Anfrage an übergeben wird Ressourcenserver'y, das bestimmt, ob das Token gültig ist. ID-Token stellt etwas völlig anderes dar.
ID-Token ist ein JWT
ID-Token ist eine speziell formatierte Zeichenfolge, die als JSON Web Token oder JWT bekannt ist (Manchmal werden JWT-Tokens wie „Jots“ ausgesprochen.). Für außenstehende Beobachter mag JWT wie unverständliches Kauderwelsch erscheinen, aber Kunden kann verschiedene Informationen aus dem JWT extrahieren, wie z. B. ID, Benutzername, Kontoanmeldezeit, Ablaufdatum ID-Token'a, das Vorhandensein von Versuchen, in das JWT einzugreifen. Daten im Inneren ID-Token'a werden genannt Anwendungen [Ansprüche].
Im Fall von OIDC gibt es auch eine Standardmethode Kunden kann zusätzliche Informationen über die Person anfordern [Identität] aus Autorisierungsserver'a, zum Beispiel eine E-Mail-Adresse mit Zugangstoken.
Erfahren Sie mehr über OAuth und OIDC
Deshalb haben wir kurz besprochen, wie OAuth und OIDC funktionieren. Bereit, tiefer zu graben? Hier finden Sie zusätzliche Ressourcen, die Ihnen helfen, mehr über OAuth 2.0 und OpenID Connect zu erfahren:
Wie immer können Sie gerne einen Kommentar abgeben. Um über unsere neuesten Nachrichten auf dem Laufenden zu bleiben, abonnieren Sie и Okta für Entwickler!
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com