XAuth und OAuth - Revision history

Sengpieh: /* Fazit */

2010-08-16T13:44:26Z

Fazit

← Older revision		Revision as of 13:44, 16 August 2010
Line 25:		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:

Sengpieh: /* Umsetzung */

2010-08-16T13:37:01Z

Umsetzung

← Older revision		Revision as of 13:37, 16 August 2010
Line 44:		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.

Sengpieh: /* Motivation */

2010-08-16T13:36:15Z

Motivation

← Older revision		Revision as of 13:36, 16 August 2010
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 ===

Sengpieh: /* Umsetzung */

2010-08-16T13:32:09Z

Umsetzung

← Older revision		Revision as of 13:32, 16 August 2010
Line 50:		Line 50:
	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.

Sengpieh: /* Fazit */

2010-08-16T13:15:50Z

Fazit

← Older revision		Revision as of 13:15, 16 August 2010
Line 25:		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 den Benutzer im Web personalisierte Dienste anzubieten. Dazu ist insgesamt pro aufgerufener Seite nur ein Request notwendig.

	Nachteile:		Nachteile:
	* nur ein Token pro Extender möglich		* nur ein Token pro Extender möglich

Sengpieh: /* Quellen */

2010-08-16T13:13:58Z

Quellen

← Older revision		Revision as of 13:13, 16 August 2010
Line 61:		Line 61:
	* [2] introducing XAuth. URL http://blog.meebo.com/?p=2391		* [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		* [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

Sengpieh: /* OAuth */

2010-08-16T13:12:53Z

OAuth

← Older revision		Revision as of 13:12, 16 August 2010
Line 32:		Line 32:

	== OAuth ==		== 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 er 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.

			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==		==Quellen==

Sengpieh at 12:47, 16 August 2010

2010-08-16T12:47:38Z

← Older revision		Revision as of 12:47, 16 August 2010
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

Sengpieh: /* XAuth - Extended Authentication */

2010-08-16T12:44:08Z

XAuth - Extended Authentication

← Older revision		Revision as of 12:44, 16 August 2010
Line 1:		Line 1:


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

	== XAuth - Extended Authentication ==		== XAuth - Extended Authentication ==

Sengpieh: /* Identity Management im Web */

2010-08-16T12:40:27Z

Identity Management im Web

← Older revision		Revision as of 12:40, 16 August 2010
Line 1:		Line 1:
	==Identity Management im Web==

⚫	=== XAuth - Extended Authentication ===

		⚫	== XAuth - Extended Authentication ==
⚫	==== 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:
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 ====		=== 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 ====		=== 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 ===		== OAuth ==