XAuth und OAuth: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:



Die beiden folgenden Verfahren sind als Identity Management im Web zu klassifizieren.
Die beiden folgenden Verfahren sind als Identity Management im Web zu klassifizieren.
Line 33: Line 32:


== OAuth ==
== OAuth ==

==Quellen==

* [1] Homepage XAuth. URL http://xauth.org
* [2] introducing XAuth. URL http://blog.meebo.com/?p=2391
* [3] XAuth verrät, wer welche Dienste nutzt. URL http://www.golem.de/1004/74568.html

Revision as of 12:47, 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 den 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

Quellen