OAuth

OAuth, das jetzt OAuth 2.0 heißt, ist ein offener Standard für die API-Autorisierung. Er definiert, wie ein API-Client die Sicherheitstoken erhält, die eine Reihe von Berechtigungen für die von dieser API bereitgestellten Ressourcen enthalten. Diese Berechtigungen orientieren sich häufig an der Einwilligung des Benutzers, der diese Ressourcen „besitzt.“ Die Token werden vom Client an seine API-Meldungen angehängt und dienen auf diese Weise als Nachweis der Berechtigung des Clients für den Zugriff auf angefragte Ressourcen.

Anstatt von einem Benutzer zu verlangen, dass er seine Anmeldeinformationen einer Anwendung weitergibt, damit diese auf eine weitere Anwendung zugreifen kann, delegiert OAuth die Autorisierungsentscheidungen an einen separaten Autorisierungsserver, der das Benutzerkonto hostet. Im Wesentlichen handelt OAuth im Namen des Benutzers und bietet delegierten Zugang zu einem Drittanbieterdienst, ohne dass der Benutzer seine Anmeldeinformationen an diesen Drittanbieter weitergeben braucht.

Wenn Sie z. B. ein Konto bei YouTube einrichten möchten und YouTube Ihnen die Möglichkeit bietet, sich mit Ihren Google-Anmeldedaten anzumelden, erhalten Sie mit diesen Daten die Autorisierung für den Zugriff auf YouTube-Ressourcen, ohne jemals dort Ihre Daten angeben zu müssen.

Hinweis: Die beiden verfügbaren Spezifikationen sind OAuth 1.0a und OAuth 2.0. Sie unterscheiden sich voneinander, können nicht gemeinsam verwendet werden und sind nicht abwärtskompatibel. Die meisten Leute verwenden heute jedoch OAuth 2.0, daher werden wir uns hier mit dieser Spezifikation befassen.  

Das Einchecken in ein Hotel ist ein weiteres Beispiel für die Funktionsweise von OAuth. Sie gehen zur Rezeption und legen zur Authentifizierung Ihren Personalausweis vor. Anschließend händigt Ihnen der Portier am Schalter anhand dieser Information eine Hotelschlüsselkarte aus.

Mit Ihrer Schlüsselkarte haben Sie Zugang zu Ihrem Zimmer, zum Pool und zum Fitnessraum. Sie werden damit jedoch keinen Zugang zu den Wäscheschränken erhalten, um sich selbst zusätzliche Handtücher zu holen, da Sie dazu nicht berechtigt sind.  

Der Autorisierungsprozess bei OAuth ist vergleichbar mit dem Hotel-Check-In.

• Das Hotel kann Ihren den Zugang jederzeit wieder entziehen, ebenso wie der Autorisierungsserver die Zugriffsberechtigung jederzeit widerrufen kann.
  
  
• YAuf Ihrer Schlüsselkarte sind weder Ihre Identität noch Ihre Anmeldedaten gespeichert, und auch das vom Autorisierungsserver gewährte Zugriffstoken muss keine Benutzerinformationen enthalten.
  
  
• Sie können Ihre Schlüsselkarte für den Zugang zu mehreren Hotelressourcen verwenden. In ähnlicher Weise ermöglicht das Zugriffstoken den Zugang zu bestimmten Ressourcen und schließt andere Ressourcen aus.
  
  
• Mit dem Auschecken aus dem Hotel verfällt Ihre Schlüsselkarte. Ihr OAuth-Zugriffstoken läuft ebenfalls ab.

Wie funktioniert OAuth?

Benutzer erteilen einer einzelnen Anwendung die Erlaubnis, auf Daten in einer anderen Anwendung zuzugreifen, ohne dass sie dort ihren Benutzernamen und ihr Passwort angeben müssen. Stattdessen wird der Authentifizierungsprozess mithilfe von Zugriffstoken abgewickelt.

Diese Token enthalten Informationen über die Authentifizierungssitzung, die Benutzerkennung, eine Kennung für den Identitätsprovider, der das Token ausgestellt hat, und eine Kennung für den Client, für den das Token erstellt wurde. Die Token enthalten auch Informationen über die Dauer ihrer Gültigkeit und die Zeit, die seit Beginn des Autorisierungsprozesses verstrichen ist. 

Bei OAuth gibt es vier verschiedene Rollen:
 

• Eigentümer der Ressource: Sie sind der Eigentümer der Ressource. Als Besitzer Ihrer Daten ermächtigen Sie eine Anwendung zum Zugriff auf Ihre Kontoinformationen. 
   

• Client: Der Client ist die Anwendung, die auf Ihre Kontoinformationen zugreifen möchte. Bevor er auf die Informationen zugreifen kann, müssen Sie dies erlauben. Diese Autorisierung muss von der API validiert werden.
   

• Ressourcenserver: Der Ressourcenserver hostet geschützte Kontoinformationen von Benutzern
   

• Autorisierungsserver: Der Autorisierungsserver prüft zunächst die Identität des Benutzers und gibt dann Zugriffstoken an die Anwendung aus.

Es gibt eine Vielzahl verschiedener OAuth-Flow-Typen, aber das folgende Diagramm erklärt, wie OAuth-Flows auf hohem Niveau funktionieren.

1. Wenn Sie sich bei einer Anwendung anmelden, werden Sie dazu aufgefordert, der Client-Anwendung den Zugriff auf Ihre Kontodaten zu gestatten oder zu verweigern. 
   
   
2. Wenn Sie die Anfrage autorisieren, erhält die Client-Anwendung einen Autorisierungscode.
   
   
3. Die Anwendung legt dem Autorisierungsserver die Authentifizierung ihrer eigenen Identität sowie den Autorisierungscode vor und fordert ein Zugriffstoken an.
   
   
4. Wenn die Anwendung authentifiziert und der Autorisierungscode gültig ist, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung aus. Zugangstoken sind vergleichbar mit Ausweisen oder Schlüsselkarten, die dem Kunden gestatten, bestimmte Aktionen in Ihrem Namen durchzuführen. Die Geltungsbereiche sind im Token enthalten und definieren diese Berechtigungen.
   
   
5. Die Anwendung fordert die Ressourcen von der API des Ressourcenservers an und übermittelt das Zugriffstoken.
   
   
6. Wenn das Zugriffstoken gültig ist, liefert die Ressourcenserver-API dem Benutzer einen Redirect-URI, der den Zugriff auf die Anwendung und die entsprechenden Ressourcen ermöglicht.
   
   

OAuth ist kein Authentifizierungsprotokoll

OAuth wird in einem breiten Spektrum von Anwendungen und auf unterschiedliche Weise verwendet, daher wird häufig angenommen, es handele sich um ein Authentifizierungsprotokoll, was allerdings nicht stimmt. Auf der Website wird sogar darauf hingewiesen. 

Ein Großteil der Verwirrung rührt daher, dass OAuth im Rahmen von Authentifizierungsprotokollen verwendet wird. Die Entwickler sehen die OAuth-Komponenten, sie interagieren mit dem OAuth-Flow und gehen davon aus, dass sie durch die Verwendung von OAuth ihre Benutzer authentifizieren können. 

OAuth kann jedoch auf viele verschiedene Weisen eingesetzt werden. Es legt kein spezifisches Token-Format oder einen allgemeinen Satz von Geltungsbereichen für das Zugriffstoken fest, es gibt nicht an, wie eine geschützte Ressource ein Zugriffstoken validieren soll, und Identitätsprovider implementieren die API-Identität auf eine andere Weise, daher ist für die Integration mit Anbietern möglicherweise ein eigener Code erforderlich.

Beispielsweise kann die Kennung eines Benutzers bei dem einem Anbieter im Feld user_id und bei einem anderen im Feld subject zu finden sein. Obwohl diese Kennungen semantisch identisch sind, würde deren Verarbeitung zwei separate Codepfade erfordern. Mit anderen Worten: Selbst wenn die Autorisierung bei jedem Anbieter gleich abläuft, kann die Art und Weise der Übermittlung unterschiedlich sein.