XAuth und OAuth: Difference between revisions
(→XAuth) |
|||
| Line 1: | Line 1: | ||
==Identity Management im Web== |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
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: |
||
| Line 14: | Line 14: | ||
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 === |
|||
Der Extender (Diensteanbieter) bietet anderen Domainen Dienste an. |
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. |
Nach erfolgreicher Authentisierung stellt dieser ein Token aus. Die Authentisierung ist kein Bestandteil von XAuth und kann mittels anderer Verfahren durchgeführt werden. |
||
| Line 22: | Line 22: | ||
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. |
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. |
Ein Quasi-Standard ermöglicht es den Benutzer im Web personalisierte Dienste anzubieten. Dazu ist insgesamt pro aufgerufener Seite nur ein Request notwendig. |
||
Nachteile: |
Nachteile: |
||
| Line 30: | Line 30: | ||
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). |
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 == |
|||
Revision as of 12:40, 16 August 2010
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).