Teil 3: So funktioniert OAuth2
Kommentare

Aus den selben Gründen wie bei OAuth1, funktioniert auch das OAuth2 Web Profile nicht für JavaScript-basierte Webanwendungen, da auch hier vorausgesetzt wird, dass ein Client Secret sicher vorgehalten wird, was im per Definition offenen JavaScript-Code nicht möglich ist.

Um trotzdem OAuth2 für diese Art von Anwendungen zu ermöglichen, wurde ein spezielles JavaScript User Agent Profile spezifiziert (Abb. 6). Hierbei öffnet die JavaScript-Anwendung als Erstes ein neues Browserfenster (oder ein iFrame; zur Vermeidung von Phishing ist allerdings ein Popup vorzuziehen, da so die Adressbar sichtbar ist), das auf den Authorization-Endpunkt zeigt, wie beim Web Profile werden auch hier Client-ID und optional Scope, State und Callback URL als Query-Parameter angehängt. Der response_type ist allerdings token:

Abb. 6: Der OAuth2-User-Agent-Profile-Protokollfluss

Abb. 6: Der OAuth2-User-Agent-Profile-Protokollfluss

GET /oauth2/authorize?response_type=token&client_id=abcdefg&state=xyz&scope=write HTTP/1.1
Host: api.twitter.com

In dem Popup kann der Nutzer dann den Client autorisieren. Danach wird der Nutzer im Popup zum Callback URL weitergeleitet. Im User Agent Profile muss dieser Callback URL für das Popup dabei denselben Host haben, wie die im öffnenden Fenster laufende, eigentliche JavaScript-Anwendung. Das Access Token für das API wird hierbei direkt im Fragmentteil des Callback URL angehängt, einen zusätzlichen Authorization-Code gibt es nicht:

HTTP/1.1 302 Found
Location: http://example.com/callback#access_token=gahorha&state=xyz&expires_in=3600

Wichtig ist, dass der Fragmentteil des URL vom Browser nicht mit zum Server, der den Content des Callback URL ausliefert, geschickt wird. Das Access Token steht also dem Backend nicht zur Verfügung. Stattdessen kann das Backend nur statisches JavaScript ausliefern, das dann das Access Token aus dem Fragmentteil des URL ausliest und eine Funktion des öffnenden Fensters (der eigentlichen Anwendung) aufruft und das Token als Parameter übergibt. Wegen der Same Origin Policy der Browser ist das nur möglich, wenn JavaScript-Anwendung und Callback URL im Popup denselben Hostnamen besitzen. Die Same Origin Policy ist also die Basis des Security-Konzepts des User Agent Profiles. Danach wird das Popup-Fenster nicht mehr benötigt und kann geschlossen werden (Listing 6). Die JavaScript-Anwendung besitzt nun eine Access Token und kann es nutzen, um zum Beispiel per JSONP oder Ajax und Cross-Origin Resource Sharing (CORS) Requests an das API zu schicken.

Listing 6
var fragmentString = location.hash.substr(1);
var fragment = {};
var fragmentItemStrings = fragmentString.split('&');
for (var i in fragmentItemStrings) {
var fragmentItem = fragmentItemStrings[i].split('=');
if (fragmentItem.length !== 2) {
continue;
}
fragment[fragmentItem[0]] = fragmentItem[1];
}
opener.setAccessToken(fragment['access_token']);
window.close();

Native Anwendungen

Für native (mobile oder Desktop-)Anwendungen sind in der OAuth2-Spezifikation verschiedene Wege beschrieben, wie man den in einem Webbrowser (auch User Agent genannt) stattfindenden Autorisierungsfluss in die eigene Anwendung einbinden kann. In der Spezifikation werden hierfür die Nutzung eines externen User Agents und eines eingebetteten User Agents beschrieben. Ein externer User Agent ist ein auf dem System des Nutzers installierter Webbrowser, mit dem der Authorization-Endpunkt des API-Anbieters aufgerufen wird. Während der Autorisierung können dabei alle Sicherheitsfunktionen des Browsers sowie schon vorhandene Sessions oder Hilfsmittel wie Browser-Plug-ins oder Passwortmanager, an die sich der Nutzer gewöhnt hat, genutzt werden. Die Clientanwendung kann dann ein eigenes Protokoll für den Callback URL (z. B. meineAppCallback:// ) im System des Nutzers für sich registrieren, auf Änderungen des Fenstertitels achten, einen vorhandenen externen Server als Callback-Ziel nutzen und ihn regelmäßig anfragen, ob der Callback schon angekommen ist, oder einen eigenen lokalen Webserver aufsetzen.

Nachteilig bei einem externen User Agent ist, dass durch das Öffnen eines neuen Browserfensters und dem Verlassen der eigentlichen Clientapplikation die Usability eingeschränkt wird und der Nutzer verwirrt werden könnte, da er das Verlassen der Applikation nicht erwartet. Alternativ kann man einen User Agent in die eigene Applikation einbetten. Passwortmanager oder vorhandene Sessions mit dem API-Anbieter lassen sich so aber nicht mehr nutzen. Außerdem ist diese Lösung anfälliger für Angriffe, da der Nutzer meist keine Informationen über den tatsächlichen URL oder die genutzten TSL/SSL-Zertifikate bekommt. All diese Möglichkeiten sind in der OAuth2-Spezifikation mit all ihren Vor- und Nachteilen beschrieben.

Weiter mit: Teil 4

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

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -