Eine prägnante und leicht verständliche Erklärung von OAuth 2.0

OAuth ist ein offener Netzwerkstandard für die Autorisierung, der weltweit weit verbreitet ist, und die aktuelle Version ist 2.0. Dieser Artikel bietet eine prägnante und leicht verständliche Erklärung des Designkonzepts und des Funktionsprozesses von OAuth 2.0 basierend auf RFC 6749.

I. Anwendungsfälle

Um die Anwendungsfälle von OAuth besser zu verstehen, betrachten wir zunächst ein hypothetisches Beispiel. Angenommen, es gibt eine Website namens "Cloud Photo Printing", die die von Benutzern auf Google gespeicherten Fotos ausdrucken kann. Wenn Benutzer diesen Dienst nutzen möchten, müssen sie "Cloud Photo Printing" erlauben, ihre auf Google gespeicherten Fotos zu lesen.

Hier ist ein Schlüsselfaktor: Google erlaubt "Cloud Photo Printing" erst nach Erhalt der Autorisierung des Benutzers, diese Fotos zu lesen. Wie kann "Cloud Photo Printing" die Autorisierung des Benutzers erhalten?

Die traditionelle Methode besteht darin, dass der Benutzer "Cloud Photo Printing" seinen Google-Benutzernamen und sein Passwort mitteilt, damit "Cloud Photo Printing" die Fotos des Benutzers lesen kann. Dieser Ansatz hat jedoch viele schwerwiegende Nachteile:

1. Sicherheitsrisiko der Passwortspeicherung: Um Folgedienstleistungen anbieten zu können, speichert "Cloud Photo Printing" das Passwort des Benutzers, was große Sicherheitsrisiken birgt.
2. Sicherheitsproblem der Anmeldemethode: Google muss die Passwort-Anmeldemethode verwenden, aber die einfache Passwortanmeldung hat eine schlechte Sicherheit.
3. Mangelnde Berechtigungskontrolle: "Cloud Photo Printing" hat das Recht, auf alle vom Benutzer auf Google gespeicherten Materialien zuzugreifen, und der Benutzer kann den Umfang und die Gültigkeitsdauer der von "Cloud Photo Printing" erhaltenen Autorisierung nicht einschränken.
4. Hohe Kosten für den Widerruf der Berechtigung: Der Benutzer kann die an "Cloud Photo Printing" erteilte Berechtigung nur widerrufen, indem er das Passwort ändert. Dies führt jedoch dazu, dass alle anderen Drittanwendungen, die die Autorisierung des Benutzers erhalten haben, ungültig werden.
5. Hohes Risiko von Datenlecks: Solange eine Drittanwendung gehackt wird, führt dies zum Verlust des Passworts des Benutzers und aller durch das Passwort geschützten Daten.

Und OAuth wurde genau geboren, um diese Probleme zu lösen.

II. Nomen Definitionen

Bevor OAuth 2.0 im Detail erläutert wird, ist es notwendig, zunächst einige Fachbegriffe zu verstehen. Diese Begriffe sind äußerst wichtig für das Verständnis der nachfolgenden Inhalte, insbesondere der relevanten Diagramme.

1. Drittanwendung (Third-party Application): In diesem Artikel auch als "Client" bezeichnet, wie z. B. "Cloud Photo Printing" im Beispiel des vorherigen Abschnitts.
2. HTTP-Dienst (HTTP Service Provider): In diesem Artikel als "Dienstanbieter" abgekürzt, wie z. B. Google im Beispiel des vorherigen Abschnitts.
3. Ressourceninhaber (Resource Owner): In diesem Artikel auch als "Benutzer" bezeichnet.
4. User Agent (User Agent): In diesem Artikel bezieht sich dies auf den Browser.
5. Autorisierungsserver (Authorization Server): Das heißt, der Server, der speziell vom Dienstanbieter zur Bearbeitung der Authentifizierung verwendet wird.
6. Ressourcenserver (Resource Server): Das heißt, der Server, auf dem der Dienstanbieter die vom Benutzer generierten Ressourcen speichert. Dies kann derselbe Server wie der Authentifizierungsserver oder ein anderer Server sein.

Nachdem Sie die obigen Substantive verstanden haben, ist es nicht schwer, die Rolle von OAuth zu verstehen, nämlich dem "Client" zu ermöglichen, die Autorisierung des "Benutzers" sicher und kontrollierbar zu erhalten und dann mit dem "Dienstanbieter" zu interagieren.

III. Das Konzept von OAuth

OAuth richtet eine Autorisierungsschicht zwischen dem "Client" und dem "Dienstanbieter" ein. Der "Client" kann sich nicht direkt beim "Dienstanbieter" anmelden, sondern meldet sich bei der Autorisierungsschicht an, um den Benutzer vom Client zu unterscheiden. Das Token, das der "Client" verwendet, um sich bei der Autorisierungsschicht anzumelden, unterscheidet sich vom Passwort des Benutzers, und der Benutzer kann den Berechtigungsumfang und die Gültigkeitsdauer des Autorisierungsschicht-Tokens bei der Anmeldung festlegen.

Nachdem sich der "Client" bei der Autorisierungsschicht angemeldet hat, öffnet der "Dienstanbieter" die vom Benutzer gespeicherten Materialien für den "Client" gemäß dem Berechtigungsumfang und der Gültigkeitsdauer des Tokens.

IV. Funktionsweise

Der Funktionsweise von OAuth 2.0 ist in der folgenden Abbildung dargestellt (entnommen aus RFC 6749):

1. (A): Nachdem der Benutzer den Client geöffnet hat, fordert der Client eine Autorisierung vom Benutzer an.
2. (B): Der Benutzer stimmt zu, dem Client eine Autorisierung zu erteilen.
3. (C): Der Client verwendet die im vorherigen Schritt erhaltene Autorisierung, um ein Token vom Authentifizierungsserver anzufordern.
4. (D): Der Authentifizierungsserver authentifiziert den Client und stimmt zu, das Token auszustellen, wenn es kein Problem gibt.
5. (E): Der Client verwendet das Token, um beim Ressourcenserver die Beschaffung von Ressourcen zu beantragen.
6. (F): Der Ressourcenserver bestätigt, dass das Token korrekt ist, und stimmt zu, die Ressourcen für den Client zu öffnen.

Unter diesen sechs Schritten ist Schritt B der Schlüssel, das heißt, wie der Benutzer dem Client eine Autorisierung erteilt. Mit dieser Autorisierung kann der Client das Token erhalten und dann die Ressourcen mit dem Token beziehen. Als Nächstes werden die vier Modi für den Client zum Erhalt der Autorisierung einzeln erläutert.

V. Die Autorisierungsmodi des Clients

Der Client muss die Autorisierung des Benutzers (Autorisierungsbewilligung) einholen, bevor er das Token (Zugriffstoken) erhalten kann. OAuth 2.0 definiert die folgenden vier Autorisierungsmethoden:

1. Autorisierungscode-Modus (authorization code)
2. Vereinfachter Modus (implicit)
3. Kennwortmodus (resource owner password credentials)
4. Clientmodus (client credentials)

VI. Autorisierungscode-Modus

Der Autorisierungscode-Modus (authorization code) ist der vollständigste in seiner Funktion und der strengste in seinem Prozess unter den Autorisierungsmodi. Sein Merkmal ist, dass er über den Hintergrundserver des Clients mit dem Authentifizierungsserver des "Dienstanbieters" interagiert. Die genauen Schritte sind wie folgt:

1. (A): Der Benutzer greift auf den Client zu, und der Client leitet den Benutzer zum Authentifizierungsserver weiter.
2. (B): Der Benutzer wählt aus, ob er dem Client eine Autorisierung erteilen möchte.
3. (C): Unter der Annahme, dass der Benutzer eine Autorisierung erteilt, leitet der Authentifizierungsserver den Benutzer zum vom Client im Voraus angegebenen "Redirection URI" (Redirection URI) weiter und fügt gleichzeitig einen Autorisierungscode hinzu.
4. (D): Der Client empfängt den Autorisierungscode, fügt den vorherigen "Redirection URI" hinzu und fordert ein Token vom Authentifizierungsserver an. Dieser Schritt wird auf dem Hintergrundserver des Clients abgeschlossen und ist für den Benutzer unsichtbar.
5. (E): Der Authentifizierungsserver überprüft den Autorisierungscode und den Redirection URI. Wenn es kein Problem gibt, sendet er ein Access Token (Access Token) und ein Refresh Token (Refresh Token) an den Client.

Im Folgenden sind die für die obigen Schritte erforderlichen Parameter aufgeführt:

• Schritt A: Der URI für den Client zum Beantragen der Authentifizierung enthält die folgenden Parameter:

  • response_type: Stellt den Autorisierungstyp dar, der ein erforderlicher Parameter ist, und der Wert ist hier fest als "code" festgelegt.
  • client_id: Stellt die ID des Clients dar, die ein erforderlicher Parameter ist.
  • redirect_uri: Stellt den Redirection URI dar, der ein optionaler Parameter ist.
  • scope: Stellt den angeforderten Berechtigungsumfang dar, der ein optionaler Parameter ist.
  • state: Stellt den aktuellen Zustand des Clients dar, und es kann ein beliebiger Wert angegeben werden. Der Authentifizierungsserver gibt diesen Wert unverändert zurück.

  Zum Beispiel:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.leapcell.io

• Schritt C: Der URI, auf den der Server dem Client antwortet, enthält die folgenden Parameter:

  • code: Stellt den Autorisierungscode dar, der ein erforderlicher Parameter ist. Dieser Code hat eine sehr kurze Gültigkeitsdauer, die normalerweise auf 10 Minuten festgelegt ist, und der Client kann diesen Code nur einmal verwenden, andernfalls wird er vom Autorisierungsserver abgelehnt. Dieser Code entspricht eins zu eins der Client-ID und dem Redirection URI.
  • state: Wenn die Clientanforderung diesen Parameter enthält, muss die Antwort des Authentifizierungsservers auch genau denselben Parameter enthalten.

  Zum Beispiel:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlqweqwWxSbIA&state=xyz

• Schritt D: Die HTTP-Anforderung für den Client zum Beantragen eines Tokens vom Authentifizierungsserver enthält die folgenden Parameter:

  • grant_type: Stellt den verwendeten Autorisierungsmodus dar, der ein erforderlicher Parameter ist, und der Wert ist hier fest als "authorization_code" festgelegt.
  • code: Stellt den im vorherigen Schritt erhaltenen Autorisierungscode dar, der ein erforderlicher Parameter ist.
  • redirect_uri: Stellt den Redirection URI dar, der ein erforderlicher Parameter ist und mit dem Wert dieses Parameters in Schritt A übereinstimmen muss.
  • client_id: Stellt die Client-ID dar, die ein erforderlicher Parameter ist.

  Zum Beispiel:

POST /token HTTP/1.1
Host: server.leapcell.io
Authorization: Basic czZCaGRrwrqw0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

• Schritt E: Die vom Authentifizierungsserver gesendete HTTP-Antwort enthält die folgenden Parameter:

  • access_token: Stellt das Zugriffstoken dar, das ein erforderlicher Parameter ist.
  • token_type: Stellt den Token-Typ dar. Dieser Wert unterscheidet nicht zwischen Groß- und Kleinschreibung und ist ein erforderlicher Parameter. Es kann vom Typ Bearer oder vom Typ Mac sein.
  • expires_in: Stellt die Ablaufzeit in Sekunden dar. Wenn dieser Parameter weggelassen wird, muss die Ablaufzeit auf andere Weise festgelegt werden.
  • refresh_token: Stellt das Aktualisierungs-Token dar, das zum Abrufen des nächsten Zugriffstokens verwendet wird und ein optionaler Parameter ist.
  • scope: Stellt den Berechtigungsumfang dar. Wenn er mit dem vom Client angeforderten Umfang übereinstimmt, kann dieser Eintrag weggelassen werden.

  Zum Beispiel:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
    "access_token":"2YotnFqwrwqrqwCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOqweqweTlKWIA",
    "example_parameter":"example_value"
}

Aus dem obigen Code ist ersichtlich, dass die relevanten Parameter im JSON-Format gesendet werden (Content - Type: application/json), und in den HTTP-Headerinformationen ist klar angegeben, dass das Caching nicht zulässig ist.

VII. Vereinfachter Modus

Der vereinfachte Modus (impliziter Bewilligungstyp) durchläuft nicht den Server der Drittanwendung, sondern beantragt direkt ein Token vom Authentifizierungsserver im Browser, wobei der Schritt des "Autorisierungscodes" übersprungen wird, daher der Name. Alle Schritte werden im Browser abgeschlossen, das Token ist für den Besucher sichtbar und der Client muss nicht authentifiziert werden. Die genauen Schritte sind wie folgt:

1. (A): Der Client leitet den Benutzer zum Authentifizierungsserver weiter.
2. (B): Der Benutzer entscheidet, ob er dem Client eine Autorisierung erteilen möchte.
3. (C): Unter der Annahme, dass der Benutzer eine Autorisierung erteilt, leitet der Authentifizierungsserver den Benutzer zum vom Client angegebenen "Redirection URI" weiter und enthält das Zugriffstoken im Hash-Teil des URI.
4. (D): Der Browser sendet eine Anfrage an den Ressourcenserver, die nicht den im vorherigen Schritt empfangenen Hash-Wert enthält.
5. (E): Der Ressourcenserver gibt eine Webseite zurück, und der darin enthaltene Code kann das Token im Hash-Wert erhalten.
6. (F): Der Browser führt das im vorherigen Schritt erhaltene Skript aus und extrahiert das Token.
7. (G): Der Browser sendet das Token an den Client.

Im Folgenden sind die für die obigen Schritte erforderlichen Parameter aufgeführt:

• Schritt A: Die vom Client gesendete HTTP-Anforderung enthält die folgenden Parameter:

  • response_type: Stellt den Autorisierungstyp dar, und der Wert ist hier fest als "token" festgelegt, was ein erforderlicher Parameter ist.
  • client_id: Stellt die ID des Clients dar, die ein erforderlicher Parameter ist.
  • redirect_uri: Stellt den Redirection URI dar, der ein optionaler Parameter ist.
  • scope: Stellt den Berechtigungsumfang dar, der ein optionaler Parameter ist.
  • state: Stellt den aktuellen Zustand des Clients dar, und es kann ein beliebiger Wert angegeben werden. Der Authentifizierungsserver gibt diesen Wert unverändert zurück.

  Zum Beispiel:

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.leapcell.io

• Schritt C: Der URI, auf den der Authentifizierungsserver dem Client antwortet, enthält die folgenden Parameter:

  • access_token: Stellt das Zugriffstoken dar, das ein erforderlicher Parameter ist.
  • token_type: Stellt den Token-Typ dar. Dieser Wert unterscheidet nicht zwischen Groß- und Kleinschreibung und ist ein erforderlicher Parameter.
  • expires_in: Stellt die Ablaufzeit in Sekunden dar. Wenn dieser Parameter weggelassen wird, muss die Ablaufzeit auf andere Weise festgelegt werden.
  • scope: Stellt den Berechtigungsumfang dar. Wenn er mit dem vom Client angeforderten Umfang übereinstimmt, kann dieser Eintrag weggelassen werden.
  • state: Wenn die Clientanforderung diesen Parameter enthält, muss die Antwort des Authentifizierungsservers auch genau denselben Parameter enthalten.

  Zum Beispiel:

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

Im obigen Beispiel verwendet der Authentifizierungsserver die Spalte Location der HTTP-Headerinformationen, um die URL anzugeben, zu der der Browser weitergeleitet wird. Beachten Sie, dass der Hash-Teil dieser URL das Token enthält. Gemäß Schritt D besucht der Browser im nächsten Schritt die von Location angegebene URL, der Hash-Teil wird jedoch nicht gesendet. Im nächsten Schritt E extrahiert der vom Ressourcenserver des Dienstanbieters gesendete Code das Token im Hash.

VIII. Kennwortmodus

Im Kennwortmodus (Resource Owner Password Credentials Grant) gibt der Benutzer seinen eigenen Benutzernamen und sein Kennwort an den Client weiter, und der Client verwendet diese Informationen, um eine Autorisierung vom "Dienstanbieter" anzufordern. In diesem Modus muss der Benutzer sein Kennwort an den Client weitergeben, der Client darf das Kennwort jedoch nicht speichern. Dies wird normalerweise in Fällen verwendet, in denen der Benutzer ein hohes Vertrauen in den Client hat, z. B. wenn der Client Teil des Betriebssystems ist oder von einem bekannten Unternehmen hergestellt wird. Und der Authentifizierungsserver wird erst dann in Erwägung ziehen, diesen Modus zu übernehmen, wenn andere Autorisierungsmodi nicht ausgeführt werden können. Die genauen Schritte sind wie folgt:

1. (A): Der Benutzer gibt den Benutzernamen und das Kennwort an den Client weiter.
2. (B): Der Client sendet den Benutzernamen und das Kennwort an den Authentifizierungsserver und fordert ein Token vom Letzteren an.
3. (C): Nachdem der Authentifizierungsserver bestätigt hat, dass es kein Problem gibt, stellt er dem Client ein Zugriffstoken zur Verfügung.

In Schritt B enthält die vom Client gesendete HTTP-Anforderung die folgenden Parameter:

• grant_type: Stellt den Autorisierungstyp dar, und der Wert ist hier fest als "password" festgelegt, was ein erforderlicher Parameter ist.
• username: Stellt den Benutzernamen dar, der ein erforderlicher Parameter ist.
• password: Stellt das Kennwort des Benutzers dar, das ein erforderlicher Parameter ist.
• scope: Stellt den Berechtigungsumfang dar, der ein optionaler Parameter ist.

Zum Beispiel:

POST /token HTTP/1.1
Host: server.leapcell.io
Authorization: Basic czZCaGRSa3F0gertetewrmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w

In Schritt C sendet der Authentifizierungsserver ein Zugriffstoken an den Client, zum Beispiel:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
    "access_token":"2YotnFZqweqwreqwrpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3rewrewrtr2TlKWIA",
    "example_parameter":"example_value"
}

Die Bedeutung der verschiedenen Parameter im obigen Code kann im Abschnitt "Autorisierungscode-Modus" nachgelesen werden. Während des gesamten Prozesses darf der Client das Kennwort des Benutzers nicht speichern.

IX. Clientmodus

Der Clientmodus (Client Credentials Grant) bedeutet, dass sich der Client beim "Dienstanbieter" im eigenen Namen authentifiziert, nicht im Namen des Benutzers. Streng genommen gehört der Clientmodus nicht zu dem Problem, das das OAuth-Framework lösen muss. In diesem Modus registriert sich der Benutzer direkt beim Client, und der Client fordert den "Dienstanbieter" auf, Dienste im eigenen Namen bereitzustellen. Tatsächlich gibt es kein Autorisierungsproblem. Die genauen Schritte sind wie folgt:

1. (A): Der Client authentifiziert seine Identität beim Authentifizierungsserver und fordert ein Zugriffstoken an.
2. (B): Nachdem der Authentifizierungsserver bestätigt hat, dass es kein Problem gibt, stellt er dem Client ein Zugriffstoken zur Verfügung.

In Schritt A enthält die vom Client gesendete HTTP-Anforderung die folgenden Parameter:

• grant_type: Stellt den Autorisierungstyp dar, und der Wert ist hier fest als "client_credentials" festgelegt, was ein erforderlicher Parameter ist.
• scope: Stellt den Berechtigungsumfang dar, der ein optionaler Parameter ist.

Zum Beispiel:

POST /token HTTP/1.1
Host: server.leapcell.io
Authorization: Basic czZCaGRSqeqwewqmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials

Der Authentifizierungsserver muss die Identität des Clients auf irgendeine Weise überprüfen.

In Schritt B sendet der Authentifizierungsserver ein Zugriffstoken an den Client, zum Beispiel:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
    "access_token":"2Yotnqweqwe1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "example_parameter":"example_value"
}

Die Bedeutung der verschiedenen Parameter im obigen Code kann im Abschnitt "Autorisierungscode-Modus" nachgelesen werden.

X. Aktualisieren des Tokens

Wenn das "Zugriffstoken" des Clients bei der Anmeldung des Benutzers abgelaufen ist, muss das "Aktualisierungs-Token" verwendet werden, um ein neues Zugriffstoken anzufordern. Die vom Client zum Aktualisieren des Tokens gesendete HTTP-Anforderung enthält die folgenden Parameter:

• grant_type: Stellt den verwendeten Autorisierungsmodus dar, und der Wert ist hier fest als "refresh_token" festgelegt, was ein erforderlicher Parameter ist.
• refresh_token: Stellt das zuvor empfangene Aktualisierungs-Token dar, das ein erforderlicher Parameter ist.
• scope: Stellt den angeforderten Autorisierungsumfang dar, der den Umfang der vorherigen Anwendung nicht überschreiten darf. Wenn dieser Parameter weggelassen wird, bedeutet dies dasselbe wie der vorherige.

Zum Beispiel:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzqeqweqwmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Leapcell: Die Serverlose Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis

Abschließend empfehle ich die beste Plattform für die Bereitstellung: Leapcell

1. Multi-Sprachen Support

• Entwickeln Sie mit JavaScript, Python, Go oder Rust.

2. Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung — keine Anfragen, keine Gebühren.

3. Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

4. Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

5. Mühelose Skalierbarkeit und hohe Leistung

• Automatische Skalierung zur einfachen Bewältigung hoher Gleichzeitigkeit.
• Null Betriebsaufwand — Konzentrieren Sie sich einfach auf den Aufbau.

Erfahren Sie mehr in der Dokumentation!

Leapcell Twitter: https://x.com/LeapcellHQ