Die erste Version von OAuth 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.

Abb. 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 Secret gehasht. Hierfür stehen verschiedene Hashing-Algorithmen zur Verfügung. Auf Providerseite wird für den eingehenden Request ebenfalls eine Signatur erstellt und diese dann mit der ankommenden Signatur verglichen. Somit ist sichergestellt, dass der Request zwischendurch nicht manipuliert wurde und wirklich vom korrekten Client abgeschickt worden ist, da er neben dem Provider der Einzige ist, der das geteilte Secret kennt. Durch den im Request befindlichen Zeitstempel und Nonce-Wert kann zudem sichergestellt werden, dass der Request und die Signatur erst vor Kurzem erstellt und, indem der Anbieter sich den Nonce-Wert merkt, nicht schon einmal zuvor abgeschickt worden sind. Der Provider generiert nun ein Request Token und Request Token Secret, merkt sich Consumer Key und Callback URL für dieses Token und schickt es inklusive dem Request Token Secret an den Client zurück (Listing 1).

Listing 1

//Beispiel
POST /oauth/request_token HTTP/1.1
Host: api.twitter.com
Authorization: OAuth oauth_consumer_key = "abcdef",
oauth_signature_method = "HMAC-SHA1",
oauth_timestamp = "137131200",
oauth_nonce = "gggg",
oauth_callback = "http%3A%2F%2Fexample.com%2Fcallback"
oauth_signature = "..."
//Antwort
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencode

oauth_token=defghi&oauth_token_secret=jklmnop&oauth_callback_confirmed=true

Hat der Client das Request Token erhalten, leitet er den User im Browser über einen HTTP Redirect an den Authorization-Endpunkt des Providers weiter. Dabei hängt er das zuvor erhaltene Request Token an den Weiterleitungs-URL an:

HTTP/1.1 302 Found
Location: https://api.twitter.com/oauth/authorization?oauth_token=defghi

Am Authorization-Endpunkt kann sich der Nutzer dann beim Provider einloggen und den Client autorisieren, auf seine Daten zuzugreifen. Hat er das gemacht, erstellt der Provider einen Verifier, bindet ihn intern an das Request Token, den Consumer Key und den autorisierenden Nutzer und leitet ihn an den im ersten Schritt angegebene Callback URL zurück. Der erstellte Verifier sowie das autorisierte Request Token werden dabei als Query-Parameter an den Callback URL angehängt:

HTTP/1.1 302 Found
Location: http://example.com/callback?oauth_token=defghi&oauth_verifier=qrstuvw

In dem Request, der auf den Callback URL reagiert, kann nun der Client mit dem Request Token, dem Verifier und seinem Consumer Key am Access-Token-Endpunkt des Providers ein Access Token und ein Accesss Token Secret abholen. Dieser Request wird ebenfalls signiert, allerdings nicht nur mit dem Consumer Secret, sondern zusätzlich auch mit dem Request Token Secret aus Schritt 1: Es werden einfach beide Secrets mit einem & zu einem Secret verknüpft, der Signaturalgorithmus ist dann derselbe (Listing 2).

Listing 2

//Beispiel
POST /oauth/access_token HTTP/1.1
Host: api.twitter.com
Authorization: OAuth oauth_consumer_key = "abcdef",
oauth_token = "defghi"
oauth_signature_method = "HMAC-SHA1",
oauth_timestamp = "137131201",
oauth_nonce = "hhhhh",
oauth_verifier = "qrstuvw"
oauth_signature = "..."
//Antwort
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencode

oauth_token=xzyabc&oauth_token_secret=defghijk

Nun besitzt der Client ein Access Token und kann es zusammen mit seinem Consumer Key, dem Consumer Secret und dem Access Token Secret benutzen, um das API anzufragen. Auch die eigentlichen API Requests müssen wiederum signiert werden. Das Secret besteht jetzt aus dem Consumer Secret und dem Access Token Secret, wie in Listing 3 zu sehen. Die komplette Spezifikation finden Sie im RFC 5849. Eine Darstellung des OAuth1-Protokollflusses zeigt Abbildung 2.

Listing 3

POST /1/statuses/update.json HTTP/1.1
Host: api.twitter.com
Authorization: OAuth oauth_consumer_key = "abcdef",
oauth_token = " xzyabc"
oauth_signature_method = "HMAC-SHA1",
oauth_timestamp = "137131203",
oauth_nonce = "iiiiiii",
oauth_signature = "..."

status=New%20Tweet&trim_user=true&include_entities=true

Abb. 2: Der OAuth1-Protokollfluss

Weiter mit: Teil 2

Alle Teile: Teil 1, Teil 2, Teil 3, Teil 4, Teil 5