Also dann wohl oAuth. Eigentlich hatte ich gehofft, das Thema ein wenig vor mir herschieben zu können, da mit ma.gnolia alle meine Links zum Thema dahin gegangen sind. Aber dem gigantischen Feedback bezüglich meines letzten Posts kann ich mich wohl nicht erwähren und sammle einfach nochmal neu 
(diesmal dann aber mit delicious)
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