XAuth und OAuth: Difference between revisions
(→Fazit) |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Identity Management im Web== |
|||
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. |
|||
| ⚫ | |||
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). |
|||
| ⚫ | |||
"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==== |
|||
[[Image: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== |
|||
* [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 |
|||
* [4] Lofi Dewanto: Autorisierungsdienste mit OAuth. URL http://www.heise.de/developer/artikel/Autorisierungsdienste-mit-OAuth-845382.html |
|||
* [5] Beginners Guide to OAuth. URL http://hueniverse.com/oauth |
|||
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
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
- [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
- [4] Lofi Dewanto: Autorisierungsdienste mit OAuth. URL http://www.heise.de/developer/artikel/Autorisierungsdienste-mit-OAuth-845382.html
- [5] Beginners Guide to OAuth. URL http://hueniverse.com/oauth