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-Applikationen 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.

Begriffe[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 Mobile-Applikation, 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 Zahlen; 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.

Geschichte[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 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.

Sicherheit[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.[1]
Ende Juli 2012 erklärte Eran Hammer, ein Redakteur des Spezifikationsdokuments für OAuth 2.0, seinen Rücktritt.[2] In einer Erklärung schreibt er, dass OAuth 2.0 im Vergleich zu 1.0 „viel komplexer, weniger interoperabel, weniger nützlich, unvollständiger und vor allem weniger sicher“ sei.[3]

Siehe auch[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Eran Hammer-Lahav: OAuth Security Advisory: 2009.1 (englisch) 23. April 2009. Abgerufen am 23. April 2009: „A session fixation attack against the OAuth Request Token approval flow (OAuth Core 1.0 Section 6) has been discovered.“
  2. http://www.heise.de/security/meldung/Entwickler-OAuth-2-0-weniger-interoperabel-und-weniger-sicher-1654840.html
  3. http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

Weblinks[Bearbeiten]