© saicle/Shutterstock.com
Der Standard für Clientautorisierung im Überblick

So funktioniert OAuth2


Das OAuth-Protokoll hat sich in den letzten Jahren zum De-facto-Standard der Clientautorisierung bei APIs entwickelt und wird von vielen großen Anbietern wie Facebook, Twitter oder Google verwendet. Grund genug, sich einmal näher damit zu beschäftigen, wie OAuth eigentlich genau funktioniert, welche Probleme es mit sich bringt, und wie diesen in der nächsten Version der Spezifikation, OAuth2, begegnet wird.

Die erste Version von OAuth [1] ist zwischen November 2006 und Oktober 2007 entstanden und wurde maßgeblich von Ingenieuren von Twitter, ma.gnolia, Yahoo und Google entwickelt. Ziel war es, ein standardisiertes Protokoll zu spezifizieren, mit dem ein Nutzer einer Webanwendung erlauben kann, in seinem Namen auf ein API, zum Beispiel das Twitter-API, zuzugreifen, ohne dass die Clientwebanwendung Kenntnisse über Nutzername und Passwort des Nutzers beim API-Anbieter haben muss.

Wie funktioniert OAuth?

Jeder Client, der ein mit OAuth geschütztes API ansprechen möchte, muss sich zuerst beim Anbieter des API, zum Beispiel Twitter, registrieren. Hierbei bekommt er vom Anbieter einen so genannten Consumer Key und ein Consumer Secret (Abb. 1) zugewiesen, die im späteren Verlauf der Autorisierung benötigt werden.

hofmann_oauth_1.tif_fmt1.jpgAbb. 1: Eine angelegte OAuth-Applikation bei Twitter

Möchte nun ein User eine Clientanwendung autorisieren, in seinem Namen auf das API des Anbieters zuzugreifen, muss sich der Client zuerst – Server zu Server – ein Request Token beim Anbieter abholen. Dazu schickt er seinen Consumer Key, einen Callback URL, einen Zeitstempel und einen Nonce-Wert zu dem Request-Token-Endpunkt des Providers und bekommt ein Request Token und ein Request Secret als Antwort zurück. Dieser Request, wie auch alle weiteren Server-zu-Server-Requests, müssen mit einer OAuth-Signatur signiert werden. Die zusätzlichen OAuth-Parameter werden normalerweise in einem OAuth Authorization Header dem Request hinzugefügt, können aber auch als Query-Parameter an den URL oder bei einem POST Request mit dem Content Type application/x-www-form-urlencoded als zusätzliche Parameter im POST Body angehängt werden. Die Signatur wird über den gesamten, normalisierten Request erstellt, das heißt, die HTTP-Methode, der URL inklusive aller sortierten Query-Parameter und einem Hash des Request Bodys beziehungsweise, falls der Request Body vom Content Type application/x-www-form-urlencoded ist, inklusive allen sortierten Parametern des Request Bodys. Der normalisierte Request wird dann mit dem Consumer ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang