Hat der erste Entwurf von OpenID Connect noch auf eine (übersichtliche) Seite gepasst, braucht der Draft der OpenID Foundation schon 7 unterschiedliche Spezifikationen.
Wieso müssen “Standard”-Organisationen wie das W3C (z.B. RDFa) oder der OpenID Foundation denn alles so unnötig kompliziert machen? Immerhin schafft es ja sogar Facebook seinen Authentifizierungsprozess auf einer Seite zu erklären. …und noch besser! Er lässt in drei Sätzen zusammenfassen:
- Hol dir über folgende URL einen Access-Token:
https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL - Häng ihn an folgende URL, auf den du den User weiterleitest:
https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=email,read_stream - Fertsch!
…dazu kommen eine weitere Discovery-Variante die Webfinger, host-meta, XRD, XRDS oder YADIS komplett ignoriert und eine Identity-API die SREG oder AX noch nicht einmal ähnelt!
Mike Jones, einer der Hauptentwickler der Spezifikation, schreibt zwar:
The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.
Das ist aber nur die halbe Wahrheit. Webseitenbetreiber, die zukünftig einen OpenID Connect Login anbieten wollen, haben es in der Tat etwas einfacher, da sie sich auf die “Minimalanforderungen” konzentrieren können. Seiten die einen OpenID Connect Provider stellen wollen haben aber folgendes Problem:
Authorization Requests can follow one of two paths; the Implicit Flow or the Authorization Code Flow. [...]
The OpenID Connect Basic Client profile only documents Clients using the Implicit Flow. OpenID Providers MUST support both flows. [...]
Damit begeht die OpenID Foundation wieder den gleichen Fehler wie bei OpenID 2.0. Am Schluss gibt es so viele unterschiedliche und halbfertige Implemenrierungen, dass man wieder auf SaaS-Dienste wie Janrain oder Gigaya zurückgreifen muss. Wozu braucht es dann noch einen “Standard”?
Warum denn immer 1000 Alternativen anbieten? Bei Facebook klappts ja auch ohne…
