TOC

Eine Einführung in OAuth 2

Einführung

OAuth 2 ist ein Autorisierungsframework, mit dem Anwendungen eingeschränkten Zugriff auf Benutzerkonten eines HTTP-Dienstes wie Facebook, GitHub und DigitalOcean erhalten. Dazu wird die Benutzerauthentifizierung an den Dienst delegiert, der das Benutzerkonto hostet, und Anwendungen von Drittanbietern werden autorisiert, auf das Benutzerkonto zuzugreifen. OAuth 2 bietet Berechtigungsabläufe für Web- und Desktopanwendungen sowie für mobile Geräte.

Dieses Informationshandbuch richtet sich an Anwendungsentwickler und bietet einen Überblick über OAuth 2-Rollen, Berechtigungsbewilligungstypen, Anwendungsfälle und Flows.

Beginnen wir mit OAuth Roles!

OAuth-Rollen

OAuth definiert vier Rollen:

  • Ressourceneigentümer

  • Klient

  • Ressourcenserver

  • Autorisierungsserver

Wir werden jede Rolle in den folgenden Unterabschnitten detailliert beschreiben.

Ressourceneigentümer: User

Der Ressourceneigentümer ist der Benutzer, der eine Anwendung zum Zugriff auf ihr Konto autorisiert. Der Zugriff der Anwendung auf das Benutzerkonto ist auf den "Umfang" der erteilten Autorisierung beschränkt (z. Lese- oder Schreibzugriff).

Ressourcen- / Autorisierungsserver: API

Der Ressourcenserver hostet die geschützten Benutzerkonten, und der Autorisierungsserver überprüft die Identität des Benutzers und gibt dann Zugriffstoken für die Anwendung aus.

Aus Sicht eines Anwendungsentwicklers erfüllt die * API * eines Dienstes sowohl die Ressourcen- als auch die Berechtigungsserverrolle. Wir werden diese beiden Rollen zusammen als Service- oder API-Rolle bezeichnen.

Kunde: Application

Der Client ist die Anwendung, die auf das Konto des Benutzers zugreifen möchte. Zuvor muss sie vom Benutzer autorisiert und von der API validiert werden.

Abstrakter Protokollfluss

Nachdem Sie eine Vorstellung von den OAuth-Rollen haben, sehen wir uns ein Diagramm an, wie sie im Allgemeinen miteinander interagieren:

image: https://assets.digitalocean.com/articles/oauth/abstract_flow.png [Abstract Protocol Flow]

Hier finden Sie eine detailliertere Erläuterung der Schritte im Diagramm:

  1. Die Anwendung fordert die Berechtigung zum Zugriff auf Serviceressourcen vom Benutzer an.

  2. Wenn der Benutzer die Anforderung autorisiert hat, erhält die Anwendung eine Autorisierungsgewährung

  3. Die Anwendung fordert ein Zugriffstoken vom Autorisierungsserver (API) an, indem sie die Authentifizierung ihrer eigenen Identität und die Berechtigungserteilung vorlegt

  4. Wenn die Anwendungsidentität authentifiziert ist und die Autorisierungsgewährung gültig ist, gibt der authorization server (API) ein Zugriffstoken für die Anwendung aus. Die Autorisierung ist abgeschlossen.

  5. Die Anwendung fordert die Ressource vom Ressourcenserver (API) an und zeigt das Zugriffstoken für die Authentifizierung an

  6. Wenn das Zugriffstoken gültig ist, stellt der Ressourcenserver (API) die Ressource für die Anwendung bereit.

Der tatsächliche Ablauf dieses Vorgangs hängt vom verwendeten Autorisierungserteilungstyp ab. Dies ist jedoch die allgemeine Idee. In einem späteren Abschnitt werden wir verschiedene Arten von Zuschüssen untersuchen.

Anwendungsregistrierung

Bevor Sie OAuth mit Ihrer Anwendung verwenden können, müssen Sie Ihre Anwendung beim Dienst registrieren. Dies erfolgt über ein Registrierungsformular im Bereich "Entwickler" oder "API" der Website des Dienstes, in dem Sie die folgenden Informationen (und möglicherweise Details zu Ihrer Anwendung) angeben:

  • Anwendungsname

  • Anwendungs-Website

  • URI oder Rückruf-URL umleiten

Der Umleitungs-URI ist der Bereich, in dem der Dienst den Benutzer umleitet, nachdem er Ihre Anwendung autorisiert (oder abgelehnt) hat, und daher der Teil Ihrer Anwendung, der Autorisierungscodes oder Zugriffstoken verarbeitet.

Kunden-ID und Kundengeheimnis

Sobald Ihre Anwendung registriert ist, gibt der Dienst "Client-Anmeldeinformationen" in Form eines Client-Bezeichners und eines Client-Geheimnisses aus. Die Client-ID ist eine öffentlich zugängliche Zeichenfolge, die von der Service-API zum Identifizieren der Anwendung und zum Erstellen von Autorisierungs-URLs verwendet wird, die den Benutzern angezeigt werden. Das Client-Geheimnis wird verwendet, um die Identität der Anwendung gegenüber der Service-API zu authentifizieren, wenn die Anwendung den Zugriff auf ein Benutzerkonto anfordert, und muss zwischen der Anwendung und der API geheim gehalten werden.

Authorization Grant

In dem obigen Abstract Protocol Flow umfassen die ersten vier Schritte das Erhalten einer Autorisierungsgewährung und eines Zugriffstokens. Der Autorisierungs-Grant-Typ hängt von der Methode ab, mit der die Anwendung die Autorisierung anfordert, sowie von den Grant-Typen, die von der API unterstützt werden. OAuth 2 definiert vier Grant-Typen, von denen jeder in verschiedenen Fällen nützlich ist:

  • * Autorisierungscode *: Wird mit serverseitigen Anwendungen verwendet

  • * Implizit *: Wird mit mobilen Apps oder Webanwendungen (Anwendungen, die auf dem Gerät des Benutzers ausgeführt werden) verwendet.

  • * Anmeldeinformationen für das Kennwort des Ressourcenbesitzers *: Wird mit vertrauenswürdigen Anwendungen verwendet, z. B. solchen, deren Eigentümer der Dienst ist

  • * Client-Anmeldeinformationen *: Wird beim Zugriff auf die Anwendungs-API verwendet

In den folgenden Abschnitten werden die Grant-Typen, ihre Anwendungsfälle und Abläufe detaillierter beschrieben.

Grant Type: Autorisierungscode

Der Grant-Typ * Autorisierungscode * wird am häufigsten verwendet, da er für serverseitige Anwendungen optimiert ist, bei denen der Quellcode nicht öffentlich zugänglich ist und die Vertraulichkeit von Client Secret gewahrt werden kann. Dies ist ein umleitungsbasierter Fluss, was bedeutet, dass die Anwendung in der Lage sein muss, mit dem user-agent zu interagieren (d. H. Webbrowser des Benutzers) und Empfangen von API-Autorisierungscodes, die über den Benutzeragenten weitergeleitet werden.

Nun werden wir den Autorisierungscode-Fluss beschreiben:

image: https://assets.digitalocean.com/articles/oauth/auth_code_flow.png [Autorisierungscode-Fluss]

Schritt 1: Link zum Autorisierungscode

Zunächst erhält der Benutzer einen Autorisierungscode-Link, der wie folgt aussieht:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=&redirect_uri=&scope=

Hier ist eine Erklärung der Link-Komponenten:

  • * https://cloud.digitalocean.com/v1/oauth/authorize*: Der Endpunkt für die API-Autorisierung

  • * client_id = *: die client ID der Anwendung (wie die API die Anwendung identifiziert)

  • * redirect_uri = *: Der Dienst leitet den Benutzeragenten um, nachdem ein Autorisierungscode erteilt wurde

  • * response_type = *: Gibt an, dass Ihre Anwendung eine Erteilung des Autorisierungscodes anfordert

  • * scope = *: Gibt die Zugriffsebene an, die die Anwendung anfordert

Schritt 2: Benutzer autorisiert die Anwendung

Wenn der Benutzer auf den Link klickt, muss er sich zuerst beim Dienst anmelden, um seine Identität zu authentifizieren (sofern er nicht bereits angemeldet ist). Dann werden sie vom Dienst aufgefordert, den Anwendungszugriff auf ihr Konto zu autorisieren oder zu verweigern. Hier ist ein Beispiel für die Eingabeaufforderung zum Autorisieren einer Anwendung:

Bild: https://assets.digitalocean.com/articles/oauth/authcode.png [Link zum Autorisierungscode]

Dieser Screenshot zeigt den Autorisierungsbildschirm von DigitalOcean, und wir können sehen, dass die App "Thedropletbook" eine Autorisierung für den "Lesezugriff" auf das Konto von "[email protected]" anfordert.

Schritt 3: Die Anwendung erhält den Autorisierungscode

Wenn der Benutzer auf "Anwendung autorisieren" klickt, leitet der Dienst den Benutzeragenten zusammen mit einem Autorisierungscode an den URI für die Anwendungsumleitung weiter, der bei der Clientregistrierung angegeben wurde. Die Weiterleitung würde ungefähr so ​​aussehen (vorausgesetzt, die Anwendung ist "dropletbook.com"):

https://dropletbook.com/callback?code=

Schritt 4: Anwendung fordert Zugriffstoken an

Die Anwendung fordert ein Zugriffstoken von der API an, indem der Autorisierungscode zusammen mit den Authentifizierungsdetails, einschließlich des client secret, an den API-Token-Endpunkt übergeben wird. Hier ein Beispiel für eine POST-Anfrage an den Token-Endpunkt von DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=&client_secret=&grant_type=authorization_code&code=&redirect_uri=

Schritt 5: Anwendung erhält Zugriffstoken

Wenn die Autorisierung gültig ist, sendet die API eine Antwort mit dem Zugriffstoken (und optional einem Aktualisierungstoken) an die Anwendung. Die gesamte Antwort sieht ungefähr so ​​aus:

{"access_token":"","token_type":"bearer","expires_in":2592000,"refresh_token":"","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"[email protected]"}}

Jetzt ist die Anwendung autorisiert! Er kann das Token verwenden, um über die auf den Zugriffsbereich beschränkte Service-API auf das Benutzerkonto zuzugreifen, bis das Token abläuft oder widerrufen wird. Wenn ein Aktualisierungstoken ausgegeben wurde, kann es verwendet werden, um neue Zugriffstoken anzufordern, wenn das ursprüngliche Token abgelaufen ist.

Grant-Typ: Implizit

Der * implizite * Grant-Typ wird für mobile Apps und Webanwendungen verwendet (d. H. Anwendungen, die in einem Webbrowser ausgeführt werden), bei denen die Client Secret-Vertraulichkeit nicht garantiert ist. Der implizite Grant-Typ ist ebenfalls ein umleitungsbasierter Ablauf, aber das Zugriffstoken wird dem Benutzeragenten zur Weiterleitung an die Anwendung übergeben, sodass er möglicherweise für den Benutzer und andere Anwendungen auf dem Gerät des Benutzers verfügbar gemacht wird. Dieser Ablauf authentifiziert auch nicht die Identität der Anwendung und stützt sich auf den Umleitungs-URI (der beim Dienst registriert wurde), um diesen Zweck zu erfüllen.

Der implizite Grant-Typ unterstützt keine Aktualisierungstoken.

Der implizite Grant-Flow funktioniert im Wesentlichen wie folgt: Der Benutzer wird aufgefordert, die Anwendung zu autorisieren, und der Autorisierungsserver gibt das Zugriffstoken an den Benutzeragenten zurück, der es an die Anwendung weiterleitet. Wenn Sie neugierig auf die Details sind, lesen Sie weiter.

image: https://assets.digitalocean.com/articles/oauth/implicit_flow.png [Implicit Flow]

Schritt 1: Implizite Autorisierungsverknüpfung

Mit dem impliziten Grant-Typ wird dem Benutzer ein Autorisierungslink angezeigt, der ein Token von der API anfordert. Dieser Link sieht genauso aus wie der Autorisierungscode-Link, außer dass ein Token anstelle eines Codes angefordert wird (beachten Sie den Antworttyp „Token“):

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=&redirect_uri=&scope=

Schritt 2: Benutzer autorisiert die Anwendung

Wenn der Benutzer auf den Link klickt, muss er sich zuerst beim Dienst anmelden, um seine Identität zu authentifizieren (sofern er nicht bereits angemeldet ist). Dann werden sie vom Dienst aufgefordert, den Anwendungszugriff auf ihr Konto zu autorisieren oder zu verweigern. Hier ist ein Beispiel für die Eingabeaufforderung zum Autorisieren einer Anwendung:

Bild: https://assets.digitalocean.com/articles/oauth/authcode.png [Link zum Autorisierungscode]

Wir können sehen, dass die "Thedropletbook App" eine Berechtigung für den "Lesezugriff" auf das Konto von "[email protected]" anfordert.

Schritt 3: Benutzeragent erhält Zugriffstoken mit Umleitungs-URI

Wenn der Benutzer auf "Anwendung autorisieren" klickt, leitet der Dienst den Benutzeragenten an den Anwendungsumleitungs-URI weiter und enthält ein URI-Fragment, das das Zugriffstoken enthält. Es würde ungefähr so ​​aussehen:

https://dropletbook.com/callback#token=

Schritt 4: User-Agent folgt dem Redirect-URI

Der Benutzeragent folgt dem Umleitungs-URI, behält jedoch das Zugriffstoken bei.

Schritt 5: Die Anwendung sendet ein Skript zum Extrahieren von Zugriffstoken

Die Anwendung gibt eine Webseite zurück, die ein Skript enthält, mit dem das Zugriffstoken aus dem vollständigen Umleitungs-URI extrahiert werden kann, den der Benutzeragent beibehalten hat.

Schritt 6: Zugriffstoken an Anwendung übergeben

Der Benutzeragent führt das bereitgestellte Skript aus und übergibt das extrahierte Zugriffstoken an die Anwendung.

Jetzt ist die Anwendung autorisiert! Er kann das Token verwenden, um über die auf den Zugriffsbereich beschränkte Service-API auf das Benutzerkonto zuzugreifen, bis das Token abläuft oder widerrufen wird.

Gewährungsart: Anmeldeinformationen für das Kennwort des Ressourcenbesitzers

Mit dem Berechtigungstyp * Ressourcenbesitzerkennwortanmeldeinformationen * gibt der Benutzer seine Dienstanmeldeinformationen (Benutzername und Kennwort) direkt an die Anwendung weiter, die die Anmeldeinformationen verwendet, um ein Zugriffstoken vom Dienst abzurufen. Dieser Grant-Typ sollte nur auf dem Autorisierungsserver aktiviert werden, wenn andere Flows nicht funktionsfähig sind. Es sollte auch nur verwendet werden, wenn der Benutzer der Anwendung vertraut (z. Es gehört dem Dienst oder dem Desktop-Betriebssystem des Benutzers.

Kennwortanmeldeinformationen fließen

Nachdem der Benutzer seine Anmeldeinformationen für die Anwendung eingegeben hat, fordert die Anwendung einen Zugriffstoken vom Autorisierungsserver an. Die POST-Anfrage könnte ungefähr so ​​aussehen:

https://oauth.example.com/token?grant_type=password&username=&password=&client_id=

Wenn die Benutzeranmeldeinformationen ausgecheckt werden, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung zurück. Jetzt ist die Anwendung autorisiert!

  • Hinweis: * DigitalOcean unterstützt derzeit nicht den Berechtigungstyp "Kennwortanmeldeinformationen", daher verweist der Link auf einen imaginären Berechtigungsserver unter "oauth.example.com".

Grant Type: Client-Anmeldeinformationen

Der Grant-Typ * client credentials * bietet einer Anwendung eine Möglichkeit, auf ihr eigenes Dienstkonto zuzugreifen. Dies kann beispielsweise hilfreich sein, wenn eine Anwendung ihre registrierte Beschreibung aktualisieren oder den URI umleiten oder über die API auf andere in ihrem Dienstkonto gespeicherte Daten zugreifen möchte.

Client-Anmeldeinformationen fließen

Die Anwendung fordert ein Zugriffstoken an, indem sie ihre Anmeldeinformationen, ihre Client-ID und ihr Client-Geheimnis an den Autorisierungsserver sendet. Eine POST-Beispielanforderung könnte wie folgt aussehen:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Wenn die Anmeldeinformationen der Anwendung ausgecheckt werden, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung zurück. Jetzt ist die Anwendung berechtigt, ein eigenes Konto zu verwenden!

  • Hinweis: * DigitalOcean unterstützt derzeit nicht den Grant-Typ für Client-Anmeldeinformationen, daher verweist der Link auf einen imaginären Autorisierungsserver unter „oauth.example.com“.

Beispiel für die Verwendung von Zugriffstoken

Sobald die Anwendung über ein Zugriffstoken verfügt, kann sie das Token verwenden, um über die auf den Zugriffsbereich beschränkte API auf das Benutzerkonto zuzugreifen, bis das Token abläuft oder widerrufen wird.

Hier ist ein Beispiel für eine API-Anfrage mit "+ curl +". Beachten Sie, dass es das Zugriffstoken enthält:

curl -X POST -H "Authorization: Bearer ""https://api.digitalocean.com/v2/"

Angenommen, das Zugriffstoken ist gültig, verarbeitet die API die Anforderung gemäß ihren API-Spezifikationen. Wenn das Zugriffstoken abgelaufen oder anderweitig ungültig ist, gibt die API einen "invalid_request" -Fehler zurück.

Token Flow aktualisieren

Wenn ein Zugriffstoken abgelaufen ist und eine Anforderung von der API gestellt wird, wird ein "Ungültiger Token-Fehler" ausgegeben. Wenn zu diesem Zeitpunkt beim Ausstellen des ursprünglichen Zugriffstokens ein Aktualisierungstoken enthalten war, kann dieses verwendet werden, um ein neues Zugriffstoken vom Autorisierungsserver anzufordern.

Hier ist eine Beispiel-POST-Anforderung, bei der ein Aktualisierungstoken verwendet wird, um ein neues Zugriffstoken zu erhalten:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=&client_secret=&refresh_token=

Fazit

Damit ist dieser OAuth 2-Leitfaden abgeschlossen. Sie sollten nun eine gute Vorstellung davon haben, wie OAuth 2 funktioniert und wann ein bestimmter Berechtigungsablauf verwendet werden sollte.

Wenn Sie mehr über OAuth 2 erfahren möchten, sehen Sie sich diese wertvollen Ressourcen an:

Related