XAuth und OAuth: Difference between revisions

From
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 6: Line 6:
=== Motivation ===
=== Motivation ===
Die Entwickler von XAuth haben es sich zur Aufgabe gemacht, die Benutzerfreundlichkeit von Webanwendungen zu erhöhen.
Die Entwickler von XAuth haben es sich zur Aufgabe gemacht, die Benutzerfreundlichkeit von Webanwendungen zu erhöhen.

Dazu zählen:
Dazu zählen:
* Anzeige der Teilnahme an einem sozialen Netzwerk,
* Anzeige der Teilnahme an einem sozialen Netzwerk,
Line 13: Line 14:
Realisiert werden diese Punkte durch eine Registrierung im Kontext des Computers des Anwenders.
Realisiert werden diese Punkte durch eine Registrierung im Kontext des Computers des Anwenders.


Es gibt einige Diskussionen bezüglich der Namensgebung. XAuth hat nichts mit der Cisco-Erweiterung IPSec zu tun und auch nichts mit dem X11-Programm.
Es gibt einige Diskussionen bezüglich der Namensgebung. XAuth hat nichts mit der Cisco-Erweiterung IPSec zu tun und auch nichts mit dem X11-Programm.


=== Umsetzung/Begrifflichkeiten ===
=== Umsetzung/Begrifflichkeiten ===
Line 24: Line 25:


=== Fazit ===
=== Fazit ===
Ein Quasi-Standard ermöglicht es den Benutzer im Web personalisierte Dienste anzubieten. Dazu ist insgesamt pro aufgerufener Seite nur ein Request notwendig.
Ein Quasi-Standard ermöglicht es dem Benutzer im Web personalisierte Dienste anzubieten. Dazu ist insgesamt pro aufgerufener Seite nur ein Request notwendig.


Nachteile:
Nachteile:
Line 43: Line 44:
Ausschließlich ein Autorisierungs- und Datenaustauschprotokoll werden definiert. Die Sicherheit basiert auf anderen kryptografischen Protokollen und Funktionen.
Ausschließlich ein Autorisierungs- und Datenaustauschprotokoll werden definiert. Die Sicherheit basiert auf anderen kryptografischen Protokollen und Funktionen.


Damit ein Konsument diese Verfahren nutzen kann, muss er sich zuvor auf physischem Weg beim Provider registriert haben. Anschließend erhält er seine Identifikationsdaten und Schlüssel für die kryptografischen Funktionen.
Damit ein Konsument diese Verfahren nutzen kann, muss er sich zuvor auf physischem Weg beim Provider registriert haben. Anschließend erhält der Konsument seine Identifikationsdaten und Schlüssel für die kryptografischen Funktionen.


Die Kommunikation wird wiederum über s.g. Token realisiert, die zwischen dem Konsumenten und dem Provider im HTTP-Request als GET-Parameter hin- und hergeschickt werden.
Die Kommunikation wird wiederum über s.g. Token realisiert, die zwischen dem Konsumenten und dem Provider im HTTP-Request als GET-Parameter hin- und hergeschickt werden.
Line 50: Line 51:
Die Authentisierung selbst findet direkt über einen HTTPS-Kanal mit dem Provider statt. Das dabei verwendete Verfahren ist nicht vorgegeben.
Die Authentisierung selbst findet direkt über einen HTTPS-Kanal mit dem Provider statt. Das dabei verwendete Verfahren ist nicht vorgegeben.
Dem Konsumenten werden die Login-Daten niemals bekanntgegeben.
Dem Konsumenten werden die Login-Daten niemals bekanntgegeben.

====Protokollablauf====

[[Image:OAuth-Protokoll.jpeg]]


Zur Verhinderung von Replay-Attacken sollten Zeitstempel oder s.g. Nonces verwendet werden.
Zur Verhinderung von Replay-Attacken sollten Zeitstempel oder s.g. Nonces verwendet werden.

Latest revision as of 13:44, 16 August 2010

Die beiden folgenden Verfahren sind als Identity Management im Web zu klassifizieren.

XAuth - Extended Authentication

Motivation

Die Entwickler von XAuth haben es sich zur Aufgabe gemacht, die Benutzerfreundlichkeit von Webanwendungen zu erhöhen.

Dazu zählen:

  • Anzeige der Teilnahme an einem sozialen Netzwerk,
  • Personalisierung im Web,
  • dem Anwender zugeschnittene Dienste anbieten und
  • Ladezeit der Seite verringern.

Realisiert werden diese Punkte durch eine Registrierung im Kontext des Computers des Anwenders.

Es gibt einige Diskussionen bezüglich der Namensgebung. XAuth hat nichts mit der Cisco-Erweiterung IPSec zu tun und auch nichts mit dem X11-Programm.

Umsetzung/Begrifflichkeiten

Der Extender (Diensteanbieter) bietet anderen Domainen Dienste an. Nach erfolgreicher Authentisierung stellt dieser ein Token aus. Die Authentisierung ist kein Bestandteil von XAuth und kann mittels anderer Verfahren durchgeführt werden. Das Token beinhaltet ein Ablaufdatum, ein Wertfeld sowie die Liste der leseberechtigten Domainen.

Der Retriever (Dienstnutzer) versucht das Token, welches lokal gespeichert ist, auszulesen. Bei vorhander Berechtigung kann das Wertfeld ausgelesen und die darin enthaltenen Daten zur Weiterverarbeitung verwendet werden. Die Berechtigung wird über den Domainnamen der "rufenden" Domain ermittelt. Zu diesem Zeitpunkt erfolgt kein Zugriff auf die privaten Daten des Benutzer. Mit dem ausgelesenen Wert kann anschließend die API des Extenders bedient werden.

Fazit

Ein Quasi-Standard ermöglicht es dem Benutzer im Web personalisierte Dienste anzubieten. Dazu ist insgesamt pro aufgerufener Seite nur ein Request notwendig.

Nachteile:

  • nur ein Token pro Extender möglich
  • der localStorage kann einfach ausgelesen werden

Voraussetzung ist ein HTML5-fähiger Webbrowser, der die Methode window.postmessage unterstützt. Das Token wird im localStorage des Webbrowsers als JSON-Objekt gespeichert. Schlüssel ist dabei der Domainname des Extenders. Für den Zugriff auf das Token wird eine JAVA-Script-Klasse zur Verfügung gestellt (ca. 1kB).

OAuth

"An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications." [4]

Motivation

Als Anwender (Nutzer) möchte man einen Dienst einer Seite (Konsument) in Anspruch nehmen. Dieser Dienst benötigt dazu Daten einer anderen Seite (Provider), bei der der Anwender einen Account besitzt. Der springende Punkt ist das Mitteilen der Zugangsinformation. Gegenüber dem Konsumenten soll das verhindert werden. Die privaten Ressourcen des Nutzers sind beim Konsumenten hinterlegt.

Umsetzung

Bei OAuth handelt es sich um eine Protokollspezifikation - RFC 5849. Anzumerken sei, dass OAuth keine Erweiterung von OpenID darstellt. Ausschließlich ein Autorisierungs- und Datenaustauschprotokoll werden definiert. Die Sicherheit basiert auf anderen kryptografischen Protokollen und Funktionen.

Damit ein Konsument diese Verfahren nutzen kann, muss er sich zuvor auf physischem Weg beim Provider registriert haben. Anschließend erhält der Konsument seine Identifikationsdaten und Schlüssel für die kryptografischen Funktionen.

Die Kommunikation wird wiederum über s.g. Token realisiert, die zwischen dem Konsumenten und dem Provider im HTTP-Request als GET-Parameter hin- und hergeschickt werden. Diese werden mit den Schlüsseln signiert und/oder verschlüsselt.

Die Authentisierung selbst findet direkt über einen HTTPS-Kanal mit dem Provider statt. Das dabei verwendete Verfahren ist nicht vorgegeben. Dem Konsumenten werden die Login-Daten niemals bekanntgegeben.

Protokollablauf

OAuth-Protokoll.jpeg

Zur Verhinderung von Replay-Attacken sollten Zeitstempel oder s.g. Nonces verwendet werden.

Fazit

Als Konsument sollte man in der heuitgen Zeit OAuth in eigene Webanwendungen integrieren, falls der Datenaustausch mit anderen Web-Services gewünscht ist. Für den Zugriff auf Daten bei den global Playern (Google, Twitter und Yahoo)ist die Einbettung von OAuth zwingend notwendig. OAuth definiert einen Standard, um deren Benutzung man als Webentwickler einer Konsumentenseite nicht herumkommt.

Quellen

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=XAuth_und_OAuth&oldid=8893"