Delegation mit OAuth 1.0

In lokalen Systemen gibt es meist eine zentrale Instanz zur Authentifizierung und Autorisierung von Nutzern. Im Internet möchte man solche zentralen Instanzen möglichst vermeiden und setzt auf andere Mechanismen zur Authentifizierung und Autorisierung. In verteilten Systemen stehen Autorisierungsinformationen oft in Form von Metadaten an der geschützten Ressource. Grundsätzlich wird zwischen Impersonation und Delegation unterschieden. Bei der Impersonation gibt der Besitzer der Ressource seine persönlichen Authentifizierungsinformationen an den Client weiter, der sich dann gegen den Server mit diesen Authentifizierungsinformationen authentifiziert. Der Client nimmt die Identität des Besitzers der Ressource an und der Server erhält keine Kenntnis davon, wer sich tatsächlich authentifiziert. Bei der Delegation handelt der Client im Auftrag des Besitzers der Ressource, d. h. der Besitzer der Ressource authentifiziert sich beim Server und gibt das Ergebnis an den Client weiter, der daraufhin Zugriff auf die geschützte Ressource des Servers erhält [Kri08, S. 69 f].

OAuth-Rollen und -Begriffe nach RFC5849 [Ham10]

Das OAuth 1.0 Protokoll ist ein offener Standard und spezifiziert in RFC 5849 [Ham10] delegierten Zugriff auf geschützte Ressourcen. Es dient dazu, Dritten den Zugriff auf geschützte Ressourcen zu erlauben. Das OAuth-Protokoll führt für das traditionelle Client-Server-Modell eine dritte Rolle ein, die des Ressource Owners. Nun ist also nicht mehr der Client der Eigentümer der Ressource, sondern er handelt lediglich noch in dessen Auftrag [Ham10, Kapitel 1]. In dem hier folgenden Szenario sind folgende OAuth-Rollen von Bedeutung [Ham10, Kapitel 1.1]:

  • Client

    Der Client ist ein HTTP-Client, der in der Lage ist, OAuth-authentifizierte Requests abzusetzen. Er ist also die Entität, welche auf eine Ressource zugreifen möchte, die ihm nicht gehört, handelt aber im Auftrag des Besitzers der Ressource.

  • Server

    Der Server ist ein HTTP-Server, der in der Lage ist, OAuth-authentifizierte Requests anzunehmen. Der Server ist die Entität, welche geschützte Ressourcen bereitstellt.

  • Resource Owner (Besitzer der Ressource)

    Der Resource Owner ist die Entität, die in der Lage ist, auf eine geschützte Ressource zuzugreifen und zu kontrollieren, indem sie sich mit ihren Credentials (Zugansdaten) beim Server authentifiziert. Dem Resource Owner gehört die Ressource. Dabei ist eine geschützte Ressource eine zugriffsbeschränkte Ressource, die vom Server bereitgestellt wird und über einen OAuth-authentifizierten Request abgerufen werden kann.

Bei OAuth kann der Besitzer einer Ressource (Ressource Owner) einem Dritten (Client) die Erlaubnis erteilen, auf seine privaten Ressourcen zuzugreifen, die von einer anderen Anwendung (Server) verwaltet werden, ohne alle Details seiner Zugangsberechtigung zur anderen Anwendung preiszugeben. Diese Erlaubnis wird in Form eines Tokens und einem passenden Shared-Key ausgedrückt. Damit ist es nicht mehr erforderlich, dass der Ressource Owner dem Client sein Geheimnis preisgibt. Durch die Nutzung eines Tokens ist es möglich, den Zugriff beliebig einzuschränken, d. h. im Umfang der gewährten Rechte und im Hinblick auf die Gültigkeitsdauer. Anwendungsfälle für OAuth findet man z. B. bei Twitter, Yahoo, AOL, Google, Flickr und Amazon.

072513_1140_delegationm1

Abbildung 1: Kommunikationsparter beim OAuth-Protokoll

Der OAuth-Prozess ist vergleichbar mit dem OpenID-Prozess. Die beiden Protokolle haben jedoch unterschiedliche Einsatzbereiche. Die OpenID-Spezifikation beschäftigt sich mit Authentifizierung und Identitätsmanagement, während sich OAuth mit dem delegierten Aufruf von Webservices und dem zentralisierten Autorisierungs- und Datenaustauschprozess beschäftigt. Der Authentifizierungsprozess spielt bei OAuth eine untergeordnete Rolle.

OAuth Nachrichtenfluss

072513_1140_delegationm2

Abbildung 2: Sequenzdiagramm – OAuth Protokollfluss

Der OAuth-Protokollfluss ist in Abbildung 2 in einem Sequenzdiagramm abgebildet. Hierbei sind die Nachrichten neben den in RFC 5849 [Ham10] spezifizierten um solche ergänzt, die in den hier dargestellten Szenarien ebenfalls von Bedeutung sind:

  1. Der Ressource Owner übermittelt dem Client einen Request, eine Aufgabe auszuführen.
  2. Der Client fragt die Ressource an.
  3. Der Server antwortet mit einer Challenge.
  4. Der Client fordert vom Server ein Set temporäre Credentials in Form eines Identifiers und einem gemeinsamen Geheimnis an. Der Server sendet die temporären Credentials im Response.
  5. Der Client sendet zusammen mit den temporären Credentials einen Redirect zum Server an den Ressource Owner.
  6. Der Redirect führt zum Authentication-Reqest des Ressource Owners an den Server.
  7. Der Server sendet dem Ressource Owner eine HTML-Seite zur Eingabe der Login-Informationen und der zu delegierenden Rechte im Response.
  8. Der Ressource Owner sendet in einem erneuten Request die angeforderten Informationen an den Server und bestätigt ihm damit, dass er den Zugriff auf die geschützte Ressource durch den Client erlauben möchte. Der Ressource Owner autorisiert somit den Server, dem Client den Zugriff auf die geschützte Ressource zu gewähren.
  9. Der Server validiert den Request und initiiert einen erneuten Redirect vom Server über den Ressource Owner auf den Client.
  10. Der Redirect führt zum Request vom Ressource Owner an den Client.
  11. Der Client nutzt die temporären Credentials, um einen Satz Token-Credentials beim Server zu erhalten, welcher den Zugriff auf die geschützte Ressource ermöglicht.
  12. Der Server antwortet mit den Token-Credentials.
  13. Der Client quittiert die Erledigung der Aufgabe an den Ressource Owner.

Der vereinbarte Schlüssel wird während der gesamten Kommunikation zwischen Konsumenten und Providern innerhalb eines Requests mit angegeben.

 

 

[Ham10] E. Hammer-Lahav. (2010, Apr.) RFC 5849 – The OAuth 1.0 Protocol. [Online]. http://tools.ietf.org/html/rfc5849

[Kri08] Walter Kriha and Roland Schmitz, Internet-Security aus Software-Sicht. Berlin Heidelberg: Springer-Verlag, 2008.

Leave a Reply