OAuth 2.0 steht für „Open Authorization“ und ist ein Standard, mithilfe dessen eine Website oder Anwendung auf Ressourcen zugreifen kann, die von anderen Web-Apps für einen Nutzer gehostet werden. 2012 löste er OAuth 1.0 ab und ist heute der maßgebliche Branchenstandard für die Online-Autorisierung. OAuth 2.0 ermöglicht den Zugriff nach Zustimmung und schränkt ein, welche Aktionen der Client ausführen darf, ohne die Anmeldedaten des Nutzers zu teilen.

Auch wenn OAuth 2 hauptsächlich für Web-Anwendungen genutzt wird, ist in der Spezifikation auch beschrieben, wie diese Art von delegiertem Zugriff bei anderen Client-Typen (z. B. bei browserbasierten Anwendungen, serverseitigen Web-Anwendungen, nativen/mobilen Apps, verbundenen Geräten usw.) gehandhabt wird.

OAuth 2.0 ist ein Autorisierungsprotokoll, KEIN Authentifizierungsprotokoll. Als Solches ist es in erster Linie dafür vorgesehen, den Zugriff auf bestimmte Ressourcen zu ermöglichen, beispielsweise externe APIs oder Nutzerdaten.

OAuth 2.0 nutzt Zugriffstokens. Zugriffstokens sind Daten, die die Autorisierung zum Zugriff auf Ressourcen für den Endnutzer darstellen. OAuth 2.0 definiert kein spezielles Format für Zugriffstokens. Je nach Kontext wird jedoch häufig das „JSON Web Token (JWT)“-Format genutzt. Dieses ermöglicht es dem Aussteller der Tokens, Daten in das Token selbst aufzunehmen. Aus Sicherheitsgründen können Zugriffstokens außerdem ein Ablaufdatum haben.

Rollen sind Bestandteil der Kernspezifikation der Autorisierungsstruktur von OAuth2.0. Diese definieren die wesentlichen Komponenten eines OAuth-2.0-Systems wie folgt:

• Ressourcenbesitzer: Der Nutzer bzw. das System, der/das die geschützten Ressourcen besitzt und den Zugriff darauf erteilen kann.

• Client: Der Client ist das System, das den Zugriff auf die geschützten Ressourcen anfordert. Um auf Ressourcen zuzugreifen, muss der Client das erforderliche Zugriffstoken innehaben.

• Autorisierungsserver: Dieser Server empfängt eine Anfrage vom Client und stellt nach dessen erfolgreicher Authentifizierung und Zustimmung durch den Besitzer der Ressourcen Zugriffstokens für den Client aus. Der Autorisierungsserver hat zwei Endpunkte: den Autorisierungsendpunkt, der die interaktive Authentifizierung und die Zustimmung des Nutzers handhabt, und den Token-Endpunkt, der an einer Transaktion von Maschine zu Maschine beteiligt ist.

• Ressourcenserver: Ein Server, der die Ressourcen des Nutzers schützt und Zugriffsanfragen vom Client empfängt. Er akzeptiert und validiert ein Zugriffstoken vom Client und gibt den Zugriff auf die jeweiligen Ressourcen frei.

Die sogenannten Scopes sind ein wichtiges Konzept in OAuth 2.0. Sie dienen dazu, den genauen Grund zu spezifizieren, aus dem der Zugriff auf Ressourcen erteilt werden kann. Welche Scope-Werte zulässig sind und auf welche Ressourcen sie sich beziehen, hängt vom Ressourcenserver ab.

Der Autorisierungsserver von OAuth 2.0 erstellt nicht unbedingt direkt ein Zugriffstoken, nachdem der Ressourcenbesitzer den Zugriff autorisiert hat. Stattdessen wird zum Zwecke einer höheren Sicherheit zunächst ein Autorisierungscode ausgegeben, der dann gegen ein Zugriffstoken ausgetauscht wird. Darüber hinaus kann der Autorisierungsserver auch ein Aktualisierungstoken mit dem Zugriffstoken ausstellen. Im Gegensatz zu Zugriffstokens haben Aktualisierungstokens in der Regel lange Ablauffristen und können gegen neue Zugriffstokens ausgetauscht werden, wenn diese ablaufen. Aufgrund dieser Eigenschaften müssen Aktualisierungstokens von Clients sicher gespeichert werden.

Bevor OAuth 2.0 genutzt werden kann, muss der Client mindestens seine eigenen Anmeldedaten, d. h. eine _Client-ID _ und ein Client Secret vom Autorisierungsserver erhalten haben, um sich bei der Anforderung eines Zugriffstokens zu identifizieren und zu authentifizieren.

In OAuth 2.0 gehen Zugriffsanfragen vom Client aus, d. h. von einer mobilen App, einer Website, einer Smart-TV-App, einer Desktopanwendung usw. Tokenanforderung, -austausch und -antwort laufen folgendermaßen ab:

1. Der Client fragt beim Autorisierungsserver eine Autorisierung an, übermittelt dazu die Client-ID und das Client Secret zur Identifikation. Er gibt außerdem die Scopes und einen Endpunkt-URI (Redirect URI) an, an den das Zugriffstoken oder der Autorisierungscode gesendet werden soll.

2. Der Autorisierungsserver authentifiziert den Client und verifiziert, dass die angefragten Scopes zulässig sind.

3. Der Ressourcenbesitzer kommuniziert mit dem Autorisierungsserver, um den Zugriff zu erteilen.

4. Der Autorisierungsserver übermittelt entweder einen Autorisierungscode oder ein Zugriffstoken an den Client, je nach Grant-Typ, wie im nächsten Abschnitt erläutert. Gegebenenfalls kann auch ein Aktualisierungstoken ausgegeben werden.

5. Mit dem Zugriffstoken fordert der Client den Zugriff auf die Ressource beim Ressourcenserver an.

In OAuth 2.0 wird mit Grants ein Katalog von Schritten bezeichnet, die ein Client ausführen muss, um für den Zugriff auf die Ressource autorisiert zu werden. Die Autorisierungsstruktur sieht verschiedene Arten von Grants vor, um unterschiedliche Szenarien zu berücksichtigen:

• Autorisierungscode-Grant : Der Autorisierungsserver gibt einen einmaligen Autorisierungscode an den Client aus, der dann gegen ein Zugriffstoken ausgetauscht wird. Dies ist die beste Lösung für traditionelle Web-Apps, bei denen der Austausch sicher auf Serverseite erfolgen kann. Der Autorisierungscode kann für einseitige Apps (Single Page Apps, SPA) und mobile/native Apps verwendet werden. Allerdings kann hier das Client Secret nicht sicher gespeichert werden und die Authentifizierung während des Austauschs ist auf die Client-ID beschränkt. Eine bessere Alternative ist ein Autorisierungscode mit Proof Key for Code Exchange (PKCE), siehe unten.

• Implicit-Grant: Ein vereinfachter Ablauf, beim dem das Zugriffstoken direkt an den Client ausgegeben wird. Beim Implicit-Flow kann der Autorisierungsserver das Zugriffstoken als Parameter im Callback-URI oder als Antwort auf einen Form-Post ausgeben. Die erste Option wird aufgrund der Gefahr von Tokenverlusten mittlerweile abgelehnt.

• Autorisierungscode-Grant mit Proof Key for Code Exchange (PKCE): Dieser Autorisierungsablauf ähnelt dem Autorisierungscode-Grant, allerdings mit zusätzlichen Schritten, die für mehr Sicherheit bei mobilen/nativen Apps und SPAs sorgen.

• Grant mit Anmeldedaten des Ressourcenbesitzers: Bei diesem Grant muss der Client sich zunächst die Anmeldedaten des Ressourcenbesitzers beschaffen, die an den Autorisierungsserver übermittelt werden. Diese Art von Grant ist daher auf absolut vertrauenswürdige Clients beschränkt. Der Vorteil ist, dass keine Umleitung an den Autorisierungsserver erforderlich ist. Diese Art empfiehlt sich also für Anwendungsfälle, in denen eine Umleitung nicht machbar ist.

• Grant mit Client-Anmeldedaten: Wird für nicht-interaktive Anwendungen genutzt, z. B. für automatisierte Prozesse, Mikrodienste usw. In diesem Fall wird die Anwendung selbst über ihre Client-ID und das Client Secret authentifiziert.

• Geräteautorisierungsablauf: Ein Grant zur Verwendung durch Apps auf Geräten mit beschränkter Eingabe wie z. B. Smart-TVs.

• Aktualisierungstoken-Grant: Bei diesem Ablauf wird ein Aktualisierungstoken gegen ein neues Zugriffstoken ausgetauscht.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.