Die Idee ist alt – eigentlich ist jeder dafür – aber wenn es dann ernst wird, hat doch wieder jeder Angst davor.
Das gute alte Problem mit den Benutzernamen und den Passwörtern. Man will sich nicht für jede Seite ein neues Passwort – und, soweit sich die E-Mailadresse als Login-Name noch nicht durchgesetzt hat, gar noch einen Benutzernamen merken.
Davor, für jede Seite einfach das gleiche Passwort zu benutzen ist man selbstverständlich auch gewarnt. Man kann nie wissen, ob und wenn ja, wie gut der Seitenbetreiber gespeicherte Passwörter in seiner Datenbank verschlüsselt.
Und selbst wenn er das macht, gäbe es immernoch Möglichkeiten, das Passwort bei Bedarf einmal abzufangen. Benutzt man dann dort die selbe E-Mail-/Passwort-Konstellation wie für seinen Mailaccount, dürfte dies schon als GAU durchgehen 
Lösungen für dieses Problem sind greifbar. Eigentlich sind sie schon klar vorhanden. Ich sehe im Moment zwei Anwärter, die sich durchsetzen könnten. Je nachdem wer seine nächsten APIs freigibt könnten es schnell noch mehr werden.
Doch auch wenn es jetzt Mittel für die Lösung des Problems gibt, ist fraglich wie schnell und gut diese akzeptiert werden und welche Ängste weiterhin vorhanden sind.
Denn es stellst sich dann wieder die Frage: Will ich dem einen Anbieter meine Daten anvertrauen? Will ich gar, dass dieser eine Anbieter dann auch weiß, auf welchen Seiten ich mich wann anmelde und wie oft ich dort bin? Und natürlich die Frage, ob ich ein solchen “Master-Zugang” haben will. Wird dieser bekannt, kann sich doch jeder mit meinem Account überall anmelden – theoretisch, so könnte man zumindest auf den ersten Blick denken. In der Praxis (ob das jetzt gut oder schlecht ist bleibt dann dahingestellt) funktioniert es aber doch nicht so einfach. Zumindest die erste Anmeldung auf einer anderen Website dürfte weiterhin beim Missbrauch der Daten problematisch sein. Aber dazu dann später mehr.
Die zwei vielversprechenden Dienste von denen ich spreche schreibe sind einmal openID und einmal facebook.com.
Hier eine etwas genauere Erklärung:
openID
openID ist quasi nur für diesen genannten Zweck geschaffen worden. Es ist ein dezentrales Login-System um sich irgendwo anmelden zu können.
Dezentral heißt, dass es nicht einen Anbieter gibt, auf den man sich verlassen muss, sondern viele verschiedene.
Es läuft so ab: Ein Internetbetreiber setzt einen openID-Server auf einer bestimmten url auf. Z.B. http://meinguter.name
Dort kann sich jeder, der will, einen Account anlegen und wählt dafür einen Benutzername.
Daraus ergibt sich dann eine openID, die da wäre benutzername.meinguter.name
Genausogut kann aber auch jeder andere Betreiber einen openID-Server aufsetzen. Z.B. wäre auch http://suchtwolke.de denkbar. Die openID würde sich dann eben aus dem Benutzernamen und suchtwolke.de zusammensetzen (=> benutzername.suchtwolke.de) (Der Admin dieses Blogs hat das aber nicht vor – ist nur um ein Beispiel zu haben).
Nun kann sich jeder seinen Lieblingsanbieter aussuchen und dort seinen Account anlegen und so seine openID erhalten.
Wenn man keinem öffentlichen Anbieter vertraut, kann man sich streng genommen auch seinen eigenen openID-Server aufsetzen. Genauso wie man das mit einem eMailserver machen könnte wird das in der Praxis aber eher selten vorkommen bzw. den IT-Profis vorbehalten sein.
Und so geht es weiter:
Man Betritt eine Webseite auf der man sich anmelden / einloggen muss und die eine openID-Unterstützung hat.
Dort gibt man seine openID ein, z.B. benutzername.suchtwolke.de
Danach wird man zu dem Server des openID-Anbieters http://suchtwolke.de weitergeleitet. Dort gibt man sein Passwort ein und wird danach gefragt, welche Daten man denn an die Webseite, auf der man sich einloggen möchte, freigeben möchte. Es wird angezeigt, ob bestimmte Daten benötigt werden (required) oder optional sind.
Nach Bestätigung der freizugebenden Daten wird man zu der Website weitergeleitet und ist quasi angemeldet.
Quasi deshalb, weil es da noch ein Problem gibt: Jeder hat schon die Erfahrung gemacht, dass man sich auf den meisten Seiten nur mit gültiger E-Mail Adresse anmelden kann. Dies wird durch Klicken eines Links in einer Bestätigungs-Mail validiert.
Da der Websitebetreiber dem dezentralen openID-Server nicht vertrauen kann – er weiß nicht, ob der openID-Betreiber die E-Mail Adresse validiert hat, muss er die E-Mail Adresse selber noch validieren. Dies geschieht wahrscheinlich wiederum durch eine Bestätigungsmail.
Aber selbst wenn man sicher sein könnte, dass die Adresse validiert ist – die Implementierung dies so vorsehen würde, könnte man sich nicht sicher sein. Denn jeder könnte ja seinen eigenen openID-Server aufsetzen und einfach fälschlicherweise angeben, dass seine dort angegebene eMail-Adresse gültig ist.
Zweites Problem: Es gibt bei openID nicht ein Feld für Vor- und ein Feld für Nachnamen, sondern nur ein Feld “Fullname”. also Vor- und Zuname in einem.
Da die meisten Seitenbetreiber den Namen aufgespaltet haben wollen, muss auch dies wieder nachbearbeitet werden.
Was sich die openID-Entwickler dabei gedacht haben, weiß ich nicht. Vielleicht wollten sie einfach bequem dem Problem entgehen, dass es auch Doppelnamen oder mehrere Vornamen gibt, was meiner Meinung nach aber zu vernachlässigen wäre.
Durch die zwei Probleme stellt sich die Implementierung in die Webseite wieder etwas stressig dar, ist aber durchaus zu bewältigen.
Einmal alle Daten validiert und angepasst, geht der nächste Login per openID ganz schnell:
openID auf der Webseite eingeben, beim openID-Server das Passwort eingeben, freizugebende Daten bestätigen und drin ist man. Sollte man dauerhaft über ein Cookie auf dem Server des openID-Betreibers angemeldet sein und dort ein Häckchen dafür gesetzt haben, der entsprechenden Seite immer gleich den Datenabgleich zu erlauben ist man mit einem Klick auf der Webseite eingeloggt.
Login per facebook-API
Es sieht bzw. sah eigentlich fast so aus, als würde sich openID durchsetzen – man wartet nur noch auf den ersten “großen” Anbieter, der openID implementiert, damit möglichst viele Leute sich auch eine openID besorgen (an openID-Anbietern mangelt es nicht) aber openID ist eben bei den meisten Internetbenutzern noch gänzlich unbekannt.
Der im Moment größte und ernstzunehmendste Konkurrent für openID scheint derweil facebook.com zu sein.
In Deutschland ist facebook zwar noch relativ unbekannt – nicht zuletzt weil die ehemals als Studenten-Community gedachte Plattform noch nicht auf deutsch zu sehen ist, jedoch scheint sie doch stark im Kommen zu sein.
Die Übersetzung der Plattform ist scheinbar im Vollen Gange und wird dann wohl – so glauben zumindest viele – die Community-/Studenten-Netzwerkszene in Deutschland aufwirbeln. Nicht zuletzt aufgrund der Möglichkeiten, die facebook.com durch seine api bietet. Sollte studivz bei seiner starren Plattform bleiben, kann man gespannt sein, was daraus wird. Ist die “100 Millionen-EURO-Plattform” dann am Ende? Auch schwer vorstellbar.
So, aber zurück zum Thema, das mit eben dieser API zu tun hat:
Man kann über die API nicht nur Anwendungen für facebook.com programmieren und anbieten, man kann facebook.com auch dazu benutzen, ähnlich wie bei openID, einen Benutzer auf einer anderen Webseite anzumelden.
Hier läuft es jedoch etwas anders. In dem Falle handelt es sich um ein zentrales Anmeldesystem – alle Daten liegen bei facebook.com, die Server gehören auch facebook.com. Also nur ein großer – wenn dieser einmal ausfallen würde, kann man sich quasi nieman mehr anmelden
Die Sache läuft so, dass ein Webseitenbetreiber einen Button auf seine Internetseite setzen kann. Klickt der Besucher darauf, wird er auf eine Anmeldeseite von facebook.com geleitet. Dort wird darauf hingewiesen, dass man sich auf eine anderen Application (bzw. Webseite) anmeldet. Man gibt eMailadresse und Passwort an und wird danach wieder auf die ursprüngliche Webseite weitergeleitet ud ist dort angemeldet.
Aber auch hier wieder – das Problem mit der ersten Anmeldung.
facebook.com gibt zwar ziehmlich viele Daten frei – darunter Name und Vorname getrennt. Sowie Wohnorte, ID’s der Freunde auf facebook.com und noch einiges mehr. Jedoch scheint (zumindest habe ich sie nicht gefunden) die eMailadresse bei diesen Daten zu fehlen. Außerdem hat der Benutzer dort scheinbar keine Wahl, welche Daten er der entsprechenden Webseite freigeben will. Hier gilt dann alles oder nichts. Also gibt man alles frei, was man auch facebook.com freigegeben hat.
Die eMailadressen die bei facebook.com hinterlegt sind, wurden zwar schon validiert, aber da diese über die API nicht freigegeben werden, muss der andere Webseitenbetreiber diese wieder manuell anfordern und validieren – sofern er diese braucht.
So wird die erste Anmeldung wieder komplizierter als geplant, aber wenn man einmal registriert ist geht ein späterer Login ganz einfach.
Und der Rest?
So, das sind die zwei von denen man meint, dass sie es werden können. Welchen man mehr traut ist nun die Frage. Unterdessen legen auch andere Communityportale nach. So will xing (ehemals openbc) auch bald eine API freigeben – schauen wir ob man sich auch darüber anmelden kann. Weiter werden sicher folgen. Und wer weiß – vielleicht tut sich bei studivz ja schon etwas von dem noch niemand etwas weiß.
Gefahren?
Einerseits ist es ja ganz gut, dass nicht nur eine Lösung in der Mache ist. Dass es verschiedene Ansätze und Lösungen gibt.
Wie dies weitergeht und ob sich nun einer durchsetzen wird, ist nun die Frage.
Ansonsten sehe ich schon eine Kunterbunte Login-Seite auf jeder Website mit zich verschiedenen Möglichkeiten sich anzumelden. Wir dürfen gespannt sein.