Für den User heißt das im Klartext, dass man, nachdem man sich per openID angemeldet hat nicht mehr per Username/Passwort seine Daten nochmals zum Austausch freigeben muss, sondern die Datenfreigabe geschieht in einem Rutsch direkt bei der Anmeldung/Registrierung:

Die erneute Implementierung findet man bei www.huffingtonpost.com. Gut, die Seite interessiert den deutschen Nutzer vielleicht nicht wirklich wahnsinnig, funktioniert aber einwandfrei und zum ausprobieren mal ganz gut. Das einzige, was ich zu bemängeln weiß ist, dass ich innerhalb des Dialoges den Zugang zu meinen Daten nicht sperren konnte. Vielleicht war ich da aber nicht wirklich schlau genug, wer weiß.

Na dann hoffe ich doch, dass ich bald mal einen Post zustande bekomme, indem ich das Hybrid-Protokoll genauer erkläre

Feel free to Flattr this post at flattr.com, if you like it.

http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html

Kurz und knapp für die, die oAuth ein wenig kennen eine sehr kurze Erläuterung auf deutsch:

User snirgel macht bei yiid eine Anfrage bei Plaxo um ihre Kontakte zu importieren. Sprich, sie schickt einen Requesttoken weg, um dann von Plaxo einen Accesstoken zu erhalten. Jetzt geht sie her und fängt den Link mit dem Requesttoken (BEVOR dieser bei Plaxo landet und gegen den Accesstoken ausgetauscht wird) ab und schickt ihn an User Hugo Affenkopf. Hugo klickt nun diesen Link und kommt zur Freigabeseite von Plaxo, wo er seine Anmeldedaten eintippt und den ZUGRIFF AUF SEINE DATEN EXPLIZIT bestätigt. Ab hier wird dann oAuth zum bösen Monster was mutwillig meine Daten klaut, denn ab jetzt kann snirgel (für ca. eine halbe Stunde oder je nach Einstellung des Clients) die Kontakte von Hugo importieren.

Richtig, sicherlich ist dies ein Fall von Phishing und das brauchen wir auch gar nicht diskutieren. Was mich aber aufregt ist, dass nun zum Teil eine wirklich gut durchdachte und auch praktikable Technologie, die im Grundprinzip das Internetleben einfacherer und sicherer macht in Verruf gerät (denn wir erinnern uns an das Passwort-Antipattern und die Speicherung von Nutzerdaten auf Fremdplattformen)

LEUTE: Das Böse ist doch nicht oAuth. Das böse sind die Leute, die wiedermal all ihre Kreativität dazu benutzen den Usern zu schaden. Und mit Verlaub, dämlich sind auch alle die dies mal wieder hinbekommen jeden blöden Link zu klicken und ohne zu denken einem Zugriff auf ihre Daten zustimmen, denn die Services die ich kenne und die bereits oAuth einsetzten weisen sehr sehr deutlich darauf hin, dass man mit Klicken oder Eingabe seiner Benutzerdaten den Zugriff auf seinen Account erlaubt:

Nach Zensursula, Killerspieldiskussionen und jetzt dieser Problematik macht es bald echt keinen Spass mehr mit dem Internet. Ständig wird die Dummheit der User und die Böswilligkeit der Leute dazu benutzt alles und jedes in Frage zu stellen, nur eben nicht die Mündigkeit der Bürger.
Deswegen mein Vorschlag: Wir stellen das Internet einfach ab. Denn sobald der Router sich ins Netz ‘einwählt’, scheinen sich alle Gehirne und jegliche Vernunft plötzlich abzuschalten. Diesen Effekt können wir nur durch eine konsequente Bekämpfung dieses bösen Mediums stoppen.

So…..das musst mal raus. In diesem Sinne: Schönen (Internet)-Tag und danke für den Fisch

Nachtrag 1000: Anscheinend haben auch yahoo und google ebenso ihr oAuth erstmal dicht gemacht. Juchhu…endlich kümmert sich mal jemand um meine Sicherheit

Nochmal Nachtrag 1005: Twitter hats wohl wieder angeschaltet. Dem Internetgott sei dank

Feel free to Flattr this post at flattr.com, if you like it.

Wie wir gelernt haben, konnte -dank OpenID- eine Problematik der Webwelt bezüglich der Nutzung von Webservices gelöst werden: Das ständige Nutzername, Passwort und Registrierungswirrwarr und offen gesagt auch Generve. Ständig musst man sich ein neues Passwort merken und immer wieder die gleichen Nutzerdaten eintippen. OpenID sei dank hat das Passwortgeraffel nun ein Ende und, wir erinnern uns, dank der Erweiterungen sReg und Attribute Exchange, das ständige Eingetippe der Profildaten auch.

Während diese Problemstellung gelöst scheint, ist nun aber natürlich schon die nächste in Sicht: Der sichere Austausch von Daten zwischen zwei Services, denn hierfür bietet OpenID keine Lösung, ausser eben bis auf die wenigen Nutzerdaten, die durch sReg und AX mitgesendet werden können.

Prinzipiell ist es ja so, dass man schon viele Dinge irgendwo im Internet gespeichert hat: Flickr hat meine Bilder, LastFM weiss Bescheid über meinen Musikgeschmack und bei Delicious liegen meine Bookmarks. Möchte ich diese Daten nun aber an anderes Stelle benutzen, war bisher der einzige Weg: alles nochmal neu eingeben oder hochladen.
Wenn ich nun meine Urlaubsbilder, die ja eigentlich schon schön vorsortiert bei Flickr liegen, gerne bei einem Online-Photo-Service entwickeln lassen will, dann muss ich wohl oder übel nochmal alles sortieren und hochladen, damit ich sie auch in analog 1.0 – Form in Händen halten kann.

Wo ist denn da das Problem? Soll doch Flickr einfach die Bilder an den Müllen-Photo-Service schicken und fertig. Gute Idee! Aber woher weiß Flickr es dem Photoservice vertrauen kann, der Sevice die Photos von der snirgel schicken will und vor allem: Woher weiß Flickr, dass es auch die snirgel ist, die die Photos woanders braucht und nicht irgendjemand sonst? Die Antwort auf diese Frage lautet -natürlich-: oAuth! Denn oAuth ist ein standartisiertes Protokoll, was eine sichere und relativ einfache Authentifizierung zwischen Internetschnittstellen (APIs) ermöglicht. Das bedeutet, man hat einen Weg gefunden, wie zwei Server wissen können, das Daten von einem bestimmten User ausgetauscht werden sollen.

Im Detail sieht das ganze wie folgt aus:
Die snirgel (der User) hat ihre Bilder (protected resources) nun also bei Flickr (service provider) hochgeladen und möchte diese bei einem Photoservice (Consumer), den wir zur Einfachheit mal Photoblitz nennen, entwickeln lassen. Nun hat sie sich bei Photoblitz eingeloggt und möchte loslegen. Photoblitz, als oAuth-Consumer bietet ihr nun an, Photos von diversen Plattformen, u.a. auch Flickr, mittels Auswahlbox zu importieren. Sie klickt den Bilder-importeiren-Button bei Photoblitz und wählt Flickr aus. -Damit snirgel Flickr überhaupt auswählen kann, musste der Entwickler von Photoblitz bereits bei der Implementierung bei Flickr einen sogenannten Consumer Key und ein Consumer Secret beantragen. Dies ist notwendig, damit Flickr später weiß, dass es Photoblitz vertrauen kann-. Nach der Auswahl klickt snirgel noch den Weiter-Knopf und los gehts:

Photoblitz beantragt bei Flickr nun im Hintergrund einen Request-Token, dass ist eine Art Passierschein für den Consumer (also Photoblitz) und hat erstmal nichts mit dem User selbst zu tun, während snirgel darauf wartet, das es weiter geht.
Hat Photoblitz den Passierschien von Flickr bekommen, wird snirgel auf eine oAuth-Authorisierungsseite von Flickr weitergeleitet. Hier kann sie sich nun einloggen, womit Flickr dann gleichzeitig weiß, dass es sich um einen Zugriff auf die Bilder von User snirgel handelt (Die Eingabe von Passwort und Username laufen natürlich nur bei Flickr ab und Photoblitz bekommt davon nichts mit).
Um nun wirklich sicher zu gehen, dass snirgel auch damit einverstanden ist, dass Photoblitz die Bilder bekommen soll, muss sie bei Flickr nochmal extra den Zugriff auf die Bilder erlauben. Zudem kann sie an dieser Stelle noch ein einstellen, wie oft und wie lange Photoblitz auf die Flickr-Bilder zugreifen darf.

Nachdem snirgel nun alles bestätigt hat, merkt sich Flickr, dass und wielange/wieoft Photoblitz auf die Bilder zugreifen darf und schickt snirgel zurück zu Photoblitz. Nebenbei schickt Flickr noch einen Requesttoken(einen weiteren Passierschein) zu Photoblitz mit zurück. Dadurch weiss Photoblitz dass es jetzt anfangen kann, die Bilder zu importieren. Das heißt, die ersten Schritte waren zunächt nur dazu da, alle Berechtigungen zwischen den beiden Servern unter Einbeziehung des Users zu regeln.
Erst jetzt beginnt der eigentlicht Datenaustausch: Photoblitz schickt den erhaltenen Passierschein zu Flickr und tauscht diesen gegen einen Accesstoken um. Dies ist jetzt nur noch eine Art Empfangsberechtigungsschein, der jetzt nur noch den Datenaustausch an sich regelt. Mit dieser Empfangsberechtigung kann nun Photoblitz für den von snirgel festgelegten Zeitraum auf die Bilder von Flickr zugreifen und sie importieren.

Klingt kompliziert, ist es prinzipiell auch. Allerdings nicht für den User, denn auch hier soll er natürlich so wenig wie möglich von der ganzen Angelegenheit mitbekommen. Er sich lediglich einloggen und den Zugriff bestätigen, was ja eigentlich nicht zuviel verlangt ist und der Aufwand, im Vergleich zum neuen Zusammensuchen und Hochladen, ja schon überschaubar ist.

Die Aufmerksamen unter euch könnten jetzt anmerken: Warum muss ich mich wieder erst noch bei Flickr mit Username und Passwort einloggen, wenn ich doch eine OpenID habe, die ich sowohl bei Photobox und Flickr hinterlegt habe. Berechtigter Einwand. Doch kann man sich denken, dass dies den Entwicklern beider Standards auch schon aufgefallen ist und hierfür gerade an einer Lösung gearbeitet ist. Kann sogar sein, dass es schon eine Lösung gibt. Darauf gehe ich dann in einer der nächsten Posts etwas näher ein.

Was ich zum Schluss nochmals erwähnen möchte, da es -glaub ich- oft noch mißverstanden wird und auch durch den Beginn dieses Posts mißverstanden werden kann: oAuth ist lediglich ein Protokoll zur Autorisierung und hat nichts mit den Daten zu tun, die dann letztendlich ausgetauscht werden. Was dann wie und in welcher Form zwischen den Servern hin und hergeschickt wird steht auf einem anderen Blatt. OAuth regelt lediglich sicher und zuverlässig die Zugriffsberechtigungen.

Welches Potential aber hinter einer solchen Lösung wie oAuth steckt, was man dadurch alles anstellen kann und welche Services es wofür benutzen, erzähl ich dann beim nächsten mal.

Quellen:
hueniverse – Beginner’s Guide to oAuth – Part I
hueniverse – Beginner’s Guide to oAuth – Part II
Wikipedia

PS: Da ich mir mit dem Thema noch etwas unsicher war/bin, freue ich mich sehr über Feedback und auch Richtigstellungen, sollte ich etwas falsch erklärt haben

Feel free to Flattr this post at flattr.com, if you like it.