OAuth

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
QS-Informatik

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)
Begründung: Allgemeinverständlichkeit mindestens fragwürdig. Vorgehensweise/Theorie hinter OAuth wird ist nicht ersichtlich. --188.99.239.52 15:12, 25. Apr. 2012 (CEST)

OAuth-Logo

OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt. Es wurde von Blaine Cook und Chris Messina initiiert.

Ein Endbenutzer (User) kann mit Hilfe dieses Protokolls einer Anwendung (Consumer) den Zugriff auf seine Daten erlauben (Autorisierung), die von einer anderen Anwendung (Service) verwaltet werden, ohne alle Details seiner Zugangsberechtigung zur anderen Anwendung (Authentifizierung) preiszugeben. Der Endbenutzer kann so Dritte damit beauftragen und dazu autorisieren, sich von ihnen den Gebrauchswert von Anwendungen erhöhen zu lassen. Typischerweise wird dabei die Übermittlung von Passwörtern an Dritte vermieden.

Geschichte[Bearbeiten | Quelltext bearbeiten]

Blaine Cook
Chris Messina

OAuth wurde im November 2006 gestartet, als Blaine Cook die OpenID-Implementierung für Twitter entwickelte. Zur selben Zeit brauchte Ma.gnolia eine Lösung, die seinen Benutzern mit OpenIDs erlaubte, Dashboard Widgets zu autorisieren, ihre Dienste zu benutzen. Deshalb trafen sich Blaine Cook, Chris Messina und Larry Halff von Ma.gnolia mit David Recordon, um die Verwendung von OpenID mit den APIs von Twitter und Ma.gnolia für die Delegation der Authentifizierung zu diskutieren. Sie stimmten überein, dass es zu dieser Zeit keinen offenen Standard für eine API-Zugriffsdelegierung gab.

Das OAuth-Internetforum wurde im April 2007 für eine kleine Gruppe Implementierer angelegt, um einen Entwurfsvorschlag für ein offenes Protokoll zu schreiben. DeWitt Clinton von Google hörte von dem OAuth-Projekt und drückte sein Interesse an der Unterstützung dieser Anstrengungen aus. Im Juli 2007 gab das Team einen ersten Spezifikationsentwurf heraus. Am 3. Oktober 2007 wurde der OAuth Core 1.0 Entwurf veröffentlicht.

Auf dem 73. IETF-Treffen in Minneapolis im November 2008 wurde eine Birds-of-a-Feather-Sitzung abgehalten, um das Einbringen des Protokolls in die IETF für weitere Standardisierungsarbeiten zu diskutieren. Das Event war wohlbesucht und es gab eine breite Unterstützung für die Einrichtung einer OAuth-Arbeitsgruppe in der IETF.

Begriffe[Bearbeiten | Quelltext bearbeiten]

Service Provider
(deutsch: „Dienstanbieter“) ist eine Website oder ein Web Service, bei dem die Informationen liegen, auf die ein kontrollierter Zugriff erlaubt werden soll. Er hat die volle Kontrolle und Verantwortung für die Implementierung von OAuth. Der Service Provider muss kein Identity Provider (Anbieter für ein zentrales Identititätsmanagement; zum Beispiel OpenID) sein.
User
(deutsch: „Benutzer“) ist der Eigentümer der Informationen. Ihm soll mit OAuth die Kontrolle über seine Informationen ermöglicht werden. OAuth ist so konzipiert, dass nur die manuelle Freigabe des Users den Zugriff auf seine Daten ermöglicht.
Consumer
(deutsch: „Nachfrager“ oder „Konsument“) ist eine Applikation, die Zugriff auf die Informationen eines Users erlangen möchte. Es kann eine Website, ein Desktopprogramm, eine App, eine Set-Top-Box, etc. sein, die in jedem Fall Zugang zum Internet haben muss.
Ein Consumer Developer ist der Entwickler der Consumer-Applikation, die mit dem Service Provider interagiert.
Protected Resources
(deutsch: „geschützte Ressourcen“) sind die Informationen des Users, auf die mit Hilfe von OAuth ein kontrollierter Zugriff erlaubt werden soll. Dabei kann es sich um Daten (Fotos, Dokumente, Adressen und so weiter), Aktivitäten (das Schreiben von Blogbeiträgen, der Transfer von Geld und so weiter) oder den geschützten Zugriff auf eine URL handeln.
Token
werden an Stelle von Benutzername-Passwort-Kombinationen verwendet, um auf Ressourcen zuzugreifen. Ein Token ist meist eine Zeichenkette aus Buchstaben und Ziffern; Sonderzeichen können auch verwendet werden. Um es vor Missbrauch zu schützen soll es schwer zu erraten und passend zu einer Sicherheitsabfrage sein. OAuth unterscheidet zwischen Abfrage-Token und Zugangs-Token.

Rollen[Bearbeiten | Quelltext bearbeiten]

In OAuth 2.0 existieren vier Rollen:[1]

Resource Owner
Eine Entität welche den Zugriff auf eine geschützte Ressource gewähren kann. Ist der Resource Owner eine Person, wird dieser als End-User bezeichnet.
Resource Server
Der Server, auf welchem die geschützte Ressourcen liegen. Er ist in der Lage, auf Basis von Access Tokens, darauf Zugriff zu gewähren.
Client
Eine Anwendung, welche mit Hilfe des Resource Owner auf geschützte Ressourcen zugreifen möchte. Der Client kann auf einem Server (Web Anwendung), Desktop PC, mobilen Gerät etc. ausgeführt werden.
Authorization Server
Der Server authentisiert den Resource Owner und stellt Access Tokens für den vom Resource Owner erlaubten Anwendungsbereich (Scope) aus.

Abstrakter OAuth-2.0-Protokollfluss[Bearbeiten | Quelltext bearbeiten]

Protocol Flow von OAuth 2.0
  1. Der Client fordert eine Autorisierung vom Resource Owner an. Diese Autorisierungsanforderung kann direkt erfolgen, wird aber bevorzugt indirekt über den Authorization Server durchgeführt.
  2. Der Client erhält eine Autorisierungsgenehmigung vom Resource Owner. Die Autorisierung kann über einen von vier Autorisierungsgenehmigungen (authorisation grant types) erfolgen.
  3. Der Client fordert einen Access Token vom Authorization Server an. Hierfür nutzt er die Authentisierungsgenehmigung vom Ressource Owner.
  4. Der Authorization Server authentisiert den Client und prüft die Authentisierungsgenehmigung des Ressource Owners. Ist diese erfolgreich, stellt er einen Access Token aus.
  5. Der Client fragt die geschützten Daten beim Resource Server an. Zur Authentisierung benutzt er den Access Token.
  6. Der Resource Server prüft den Access Token und stellt, wenn gültig, die gewünschten Daten zur Verfügung.

Anwendungsfall[Bearbeiten | Quelltext bearbeiten]

Ein Benutzer (User) hat bei einem Online-Dienst F für Fotos (Service Provider) ein Benutzerkonto und einige Bilder (Protected Resources) hinterlegt. Er möchte die Bilder auf einem Dienst D für Farbdrucke (auch Consumer oder Client) ausdrucken lassen. Hierzu soll der Dienst D Zugriff auf die Bilder des Benutzers auf dem Dienst F erhalten. Da es sich um zwei unterschiedliche Dienste handelt, muss sich der Dienst D beim Dienst F autorisieren, damit der Zugriff gewährt wird. Aus Sicherheitsgründen wäre es nicht sinnvoll, dass der Benutzer seine Zugangsdaten (Benutzername und Passwort) für den Dienst F an den Dienst D übermittelt, damit dieser sich mit den Zugangsdaten authentifiziert. Denn dadurch hätte der Dienst D uneingeschränkten Zugang auf die Daten und Funktionen im Benutzerkonto beim Dienst F. Der weitere Zugriff für Dienst D könnte dann nur noch durch das Ändern des Passworts verhindert werden.

In einem solchen Fall ermöglicht OAuth dem Dienst D den Zugriff auf bestimmte vom Benutzer freigegebene Daten, meist auch nur temporär, und dies ganz ohne Preisgabe der Zugangsdaten an Dienst D.

Hierzu ist auf der Seite des Dienstes D ein Link platziert, welcher die Beschreibung „Fotos von Dienst F laden“ hat und den Vorgang initiiert. Bereits in diesem Link sind Informationen über das Vorhaben von Dienst D kodiert.

Der Protokollablauf nach OAuth 2.0 sieht in diesem Fall wie folgt aus:[1]

  1. Der Benutzer wird durch einen Link auf den Dienst F weiter geleitet, wo er sich anmelden muss (Autorisierungs-Anfrage, Authorization Request). Zusätzlich wird ihm angezeigt, welcher Dienst auf welche Daten zugreifen möchte.
  2. Der Benutzer stimmt durch einen entsprechenden Link zu (Autorisierungsgewährung, Authorization Grant), dass Dienst D auf seine Fotos zugreifen darf. Dienst F erstellt hieraus einen Autorisierungs-Code, gelegentlich auch Autorisierungs-Token oder Anfrage-Token genannt, und teilt diesen dem Dienst D mit. Parallel wird der Benutzer wieder auf die Seite des Dienstes D umgeleitet.
  3. Dienst D fragt nun Dienst F, mit dem Autorisierungs-Code, nach einem Zugangs-Token (Access-Token).
  4. Dienst F erstellt hierzu einen Zugangs-Token und übermittelt diesen an Dienst D.
  5. Dienst D kann nun konsekutive Aufrufe auf die Fotos auf Dienst F machen, bei dem er jedes mal den Zugangs-Token mit übermittelt.
  6. Hierfür liefert Dienst F die geschützten Fotos des Benutzers an den Dienst D.

Die obigen Punkte 1-6 entsprechen den Punkten A-F im Abschnitt 1.2 „Protocol Flow“ des RFC 6749.

Die Schritte 2-4 können auch zusammengefasst werden, so dass der Dienst F direkt einen Zugangs-Token an Dienst D ausstellt, ohne einen Autorisierungs-Token zu benutzen[1]

Sicherheit[Bearbeiten | Quelltext bearbeiten]

Am 23. April 2009 wurde eine Sicherheitslücke im Protokoll aufgedeckt. Sie betraf den OAuth-Authentifizierungsablauf (auch bekannt als ‚Dreibeiniges OAuth‘, englisch 3-legged OAuth) im OAuth Core 1.0 Abschnitt 6.[2]

Eran Hammer, ein bis dahin zentraler Redakteur der Spezifikation OAuth 2.0 verließ Ende Juli 2012 das Projekt,[3] weil dessen Komplexität nach seiner Einschätzung von den meisten Softwareentwicklern kaum noch sicher implementierbar sei.[4] Wie bei zunehmender Vernetzung und Interoperabilität mehr Sicherheit erreicht wird, erklärt Hammer im Interview vom 19. Oktober 2015 [5] bzgl. seiner Referenzimplementierung Oz,[6] mit den Modulen iron[7] und hawk[8] die inzwischen auch in weitere Programmiersprachen portiert wurden.

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b c Dick Hardt: RFC 6749: The OAuth 2.0 Authorization Framework. IETF, 1. Oktober 2012, S. 75, abgerufen am 27. September 2016 (englisch).
  2. Eran Hammer-Lahav: OAuth Security Advisory: 2009.1. In: oauth.net. 23. April 2009, abgerufen am 30. Juli 2016 (englisch): „A session fixation attack against the OAuth Request Token approval flow (OAuth Core 1.0 Section 6) has been discovered.“
  3. http://www.heise.de/security/meldung/Entwickler-OAuth-2-0-weniger-interoperabel-und-weniger-sicher-1654840.html
  4. http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
  5. http://5by5.tv/changelog/178
  6. https://github.com/hueniverse/oz
  7. https://github.com/hueniverse/iron
  8. https://github.com/hueniverse/hawk