PHP Magazin

PHP, JavaScript, Open Web Technologies
X

Unser neues Quickvote: Welche PHP-Version nutzt ihr?

Sicherer Zugriff auf Web-APIs durch das OAuth-Protokoll

OAuth im Detail

Die erste Spezifikation ist [2] OAuth Core 1.0 aus dem Jahr 2007. Diese Spezifikation enthielt eine im Frühjahr 2009 entdeckte Schwachstelle, durch die ein mit einer Session Fixation vergleichbarer Angriff möglich war ([3] OAuth Security Advisory: 2009.1, [4] Eran Hammer-Lahav: "Explaining the OAuth Session Fixation Attack").

Ein Angreifer konnte darüber Zugriff auf die geschützten Daten bzw. Funktionen erlangen. Die Schwachstelle wurde in [5] OAuth Core 1.0 Revision A behoben. Inzwischen ist diese Version in einem RFC der Internet Engineering Task Force (IETF) beschrieben: [6] RFC 5849 - The OAuth 1.0 Protocol. Dabei handelt es sich aber (noch) nicht um einen Internetstandard, da die Beschreibung als "Informational" spezifiziert wird.

OAuth Version 2.0 befindet sich zurzeit in der Entwicklung und soll als Internetstandard veröffentlicht werden. Bevor das Protokoll selbst beschrieben werden kann, müssen Sie seine Terminologie kennen. Oder kurz formuliert: "Wer und was ist was?"

Client, Server und Resource Owner

OAuth verwendet, wie oben schon erwähnt, drei Parteien: Den "Resource Owner" (Ressourcen-Besitzer, in der ersten Version der Spezifikation als User bezeichnet), den Client (früher als Consumer bezeichnet) und den Server (früher als Service-Provider bezeichnet), wobei Client und Resource Owner in manchen Fällen identisch sein können.

Bei der klassischen Client-Server-Authentifizierung verwendet der Client seine Zugangsdaten zum Zugriff auf seine Daten auf dem Server. Im Web 2.0 handelt der Client in vielen Fällen aber im Namen eines Dritten, egal ob Rechner oder Person, und verwendet dabei dessen Zugangsdaten. Er greift also nicht auf seine eigenen Daten zu, sondern auf die des Resource Owners, und verwendet dabei dessen Zugangsdaten statt seiner eigenen, die meist gar nicht existieren.

Protected Resource

"Protected Resource" ist eine auf dem Server gespeicherte oder vom Server bereitgestellte Resource, auf die erst nach einer Authentifizierung zugegriffen werden kann. Die "Protected Resource" gehört dem Resource Owner, der jeden Zugriff darauf autorisieren muss.

Dabei ist es egal, ob es sich um Daten, Dienste oder etwas anderes handelt. Lediglich das Zugriffsprotokoll ist festgelegt, da OAuth nur für HTTP(S)-Ressourcen spezifiziert ist. Prinzipiell könnten aber auch andere Transportprotokolle verwendet werden.

2-beinig, 3-beinig, n-beinig

OAuth verwendet die "Anzahl der Beine" (engl. Legs), um die Anzahl der beteiligten Parteien zu beschreiben. Im typischen Fall von einem Client, einem Server und einem Resource Owner wird vom 3-beinigen OAuth gesprochen. Sind Client und Resource Owner identisch, handelt der Client also in eigenem Namen, spricht man von 2-beinigem OAuth. Bei n-beinigem OAuth stehen die weiteren Beine für weitere Parteien, bzw. Fälle, in denen der Client die Zugriffe mit weiteren Clients teilt.

Credentials und Token

OAuth verwendet drei Arten von Credentials (Zugangsdaten): Client Credentials, Temporary Credentials und Token Credentials. In der ersten Version der Spezifikation wurden noch andere Begriffe verwendet: Die Client Credentials hießen "Consumer Key and Secret", die Temporary Credentials "Request Token and Secret" und die Token Credentials "Access Token and Secret". Zwecks Rückwärtskompatibilität wird in der Spezifikation weiterhin der Parametername "oauth_consumer_key" verwendet.

Mit den Client Credentials authentifiziert sich der Client gegenüber dem Server. Die Temporary Credentials werden während des Autorisierungsprozesses verwendet, um den Autorisierungs-Request zu identifizieren. Die Token Credentials werden an Stelle der Zugangsdaten des Resource Owners verwendet. Statt dem Client seine Zugangsdaten anzuvertrauen, übergibt der Resource Owner ihm die Token Credentials, die nur einige genau spezifizierte Zugriffe zulassen. Der Client verwendet die Token Credentials, um gegenüber dem Server seine Autorisierung zur Durchführung dieser Zugriffe nachzuweisen.

Gültigkeitsbereich und Lebensdauer der Token Credentials sind meist eingeschränkt. Sie können außerdem vom Resource Owner jederzeit ohne Auswirkung auf die Token Credentials anderer Clients widerrufen werden. Die Credentials bestehen aus einem Identifier und einem Secret. Der Identifier besteht meist aus einem eindeutigen, zufällig erzeugten String aus Buchstaben und Zahlen, der nicht leicht zu raten sein soll. Das Secret verhindert, dass nicht autorisierte Dritte auf die Resource zugreifen.

Das Secret wird als symmetrisches Shared Secret definiert, Client und Server verwenden also den gleichen geheimen String, der zufällig erzeugt wird. Es ist aber auch möglich, eine auf RSA basierende asymmetrische Authentifizierungsmethode zu verwenden.

 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).