Ich hatte in den letzten Monaten die Möglichkeit, mich ein bisschen intensiver mit ID4me zu beschäftigen. Nach anfänglicher Skepsis finde ich die Idee mittlerweile extrem charmant.

Im letzten Jahr haben sich einige deutsche Firmen zusammen geschlossen um mit netID bzw. VERIMI zwei konkurrierende Single-Sign-On Dienste zu entwickeln. Beide Systeme basieren zwar auf dem offenen Standard OpenID Connect, scheinen aber mindestens genauso restriktiv zu sein. netID wird nur von einer begrenzten Anzahl von Diensten angeboten und VERIMI setzt einen zentralen Account bei verimi.de voraus.

ID4me basiert zwar auch auf OpenID Connect, ist aber kein „Yet Another Login-Service“, wie ich anfangs fälschlicherweise vermutet hatte. ID4me erweitert die OpenID Spezifikation mit einer DNS-Discovery und funktioniert vollkommen dezentral.

The ID4meidentifier, consisting of a valid DNS hostname (or, potentially, of an email address), would allow users to log into any online service via a single account, similarly to the OTT-run services, but would also allow users to choose the manager of their identifier among any number of compatible providers.

[…]

To foster adoption and remove barriers to market entry, ID4me builds on public and open standards (OpenID Connect and DNSSEC) and releases all its specifications as open, royalty-free standards, submitting them to the appropriate Internet standardization bodies. Entities already running single sign-on systems based on OpenID Connect should be able to extend them to provide ID4meidentifiers quite easily.

ID4me – General overview

Wie funktioniert ID4me genau?

Der ID4me DNS Eintrag sieht wie folgt aus:

_openid.notiz.blog. 600 IN TXT "v=OID1;iss=id.test.denic.de;clp=identityagent.de"Code-Sprache: JavaScript (javascript)

Dabei steht v für die Protokoll-Version, iss für den Issuer (der Endpunkt der für die Autentifizierung verantwortlich ist) und clp für Claims Provider (der Endpunkt über den „Claims“ (beispielsweise Profildaten) abgefragt werden können).

Was macht ID4me so spannend?

Zum selbst hosten einer OpenID, braucht man eine Domain, Webspace und eine OpenID Connect – Library, außerdem muss man wissen wie man diese installiert und betreibt. Um diese Komplexität zu reduzieren hat man sich bei OpenID 1.1 schon 2006 mit dem Thema „Delegated Authentication“ beschäftigt.

If the End User’s host is not capable of running an Identity Provider, or the End User wishes to use one running on a different host, they will need to delegate their authentication. For example, if they want to use their website, http://www.example.com/, as their Identifier, but don’t have the means, or desire, to run an Identity Provider.

Klassisch braucht OpenID Connect für die „Delegation“ mindestens ein WebFinger – Dokument. Das heißt man braucht „nur“ noch eine Domain, Webspace und man muss wissen wie WebFinger funktioniert.

ID4me konzentriert sich ausschließlich auf das Prinzip der „Delegated Authentication“ und reduziert die Anforderungen auf eine Domain!

Die Domain ist dadurch an keinen festen OpenID-Provider (Issuer) gebunden und kann bei einem Umzug zu einem neuen Registrar, weiterhin auf den alten Issuer zeigen, bzw. den Issuer beliebig wechseln. Solange sich die Domain nicht ändert, sind Hoster, Domain-Registrar, OpenID-Provider oder E-Mail – Anbieter austauschbar.

Noch ein schöner Nebeneffekt: ID4me tritt nicht in Konkurrenz zu anderen OpenID Connect Providern wie beispielsweise die oben erwähnten netID oder VERIMI. Im Gegenteil, jeder dieser Anbieter sollte mit wenig Aufwand über ID4me „delegierbar“ sein.

Vor ein paar Wochen kam Marcel Weiß auf mich zu und fragte, ob ich nicht Lust hätte, mit ihm über das Thema „Open Web“ zu podcasten. Die letzte Ausgabe des OpenWeb-Podcasts ist jetzt fast 7 Jahre alt und natürlich freue ich mich wie bolle, wieder mit jemandem über mein Nischen-Thema zu sprechen 😉

Im Ernst, ich freue mich sehr, dass Marcel Interesse an dem Thema hat (und das schon seit einer ganzen Weile) und nach einem kurzen Vorgespräch haben wir auch gemerkt, dass uns der Stoff so bald nicht ausgehen wird!

Hier klicken, um den Inhalt von share.transistor.fm anzuzeigen

Die erste Ausgabe ist eine Bestandsaufnahme der letzten 15 Jahre „Open Web“ und ein kleiner Ausblick auf zukünftige Themen.

In der ersten Ausgabe der neuen Podcastreihe zum Themenkomplex ‚Open Web‘ sprechen Matthias Pfefferle und Marcel Weiß über die Evolution von OpenID, die uns einen Hinweis auf allgemeine Herausforderungen für Protokolle in der heutigen Zeit gibt; Stichwort Extrawürste der großen Teilnehmer, welche zu Balkanisierung führen. Weitere Themen sind die DSGVO und Dataportability, Mastodon, Identi.ca und wie ActivityPub aktuell OStatus als zugrundeliegendes Protokoll für dezentrale Netzwerke ablöst. Wir ordnen die Irrungen von Diaspora ein und reden last not least über die Tragödie der Microformats.

Viel Spaß beim Hören!

‚Hier & Jetzt‘ kann man per RSS-Feed abonnieren und findet man natürlich auch bei Apple Podcasts und in jeder Podcast-App.

Irgendwann letzte oder vorletzte Woche ist die Überschrift "OpenID Connect Federation 1.0 – draft XX" in meinem Feed-Reeder aufgetaucht und auf Buzz-Words wie Federation o. Ä. springe ich natürlich immer noch sofort auf!

Spezifikationen lesen, macht ja generell nicht viel Spaß, aber bei der OpenID Connect Federation 1.0 kam ich nicht mal bis zur Hälfte. Bevor man wirklich versteht was das Protokoll eigentlich macht (für mich hört es sich ähnlich an wie OpenID Connect Dynamic Client Registration), geht es um Metadaten, JSON Web Signature (JWS), JSON Web Tokens (JWT) und JSON Web Keys (JWK).

Eigentlich dachte ich, dass OpenID Connect durch OAuth 2 super simpel sein soll… Immerhin basiert ja OAuth 2 auf SSL/TLS und nicht wie OAuth 1 auf komplizierte Signaturen.

The majority of failed OAuth 1.0 implementation attempts are caused by the complexity of the cryptographic requirements of the specification. The fact that the original specification was poorly written didn’t help, but even with the newly published RFC 5849, OAuth 1.0 is still not trivial to use on the client side. The convenient and ease offered by simply using passwords is sorely missing in OAuth.

Eran Hammer

Die OpenID Foundation scheint ihre Meinung geändert zu haben… SSL scheint wohl doch nicht auszureichen.

Another problem that has been raised is the dependency on TLS as the sole protection against attacks on the transferred information. These last couple of years a number of problems with OpenSSL, which is probably the most widely used TLS library, have been discovered that put reasonable doubt into this dependency.

OpenID Connect Dynamic Client Registration

Schade, schade…

Wer eine wirkliche Alternative zu OpenID Connect sucht, der soll sich mal IndieAuth anschauen. IndieAuth kommt der ursprünglichen Idee von OpenID Connect sehr nahe und ist relativ einfach zu verstehen und auch zu implementieren!

OAuth 2 Logo

So, jetzt muss ich mich auch mal zu der OAuth Geschichte äußern! Wer nicht weiß warauf ich anspiele, der sollte sich zuerst mal Eran Hammers Blogpost durchlesen: OAuth 2.0 and the Road to Hell.

Auf alle Kritikpunkte von Eran Hammer möchte ich gar nicht eingehen… Ich kann seine Kritik durchaus verstehen und teile sie auch weitestgehend. Auch ich bin generell der Freund von schlanken Spezifikationen und hasse Standards die versuchen alles abzudecken und jedes Format zu unterstützen.

Abgesehen von den ganzen Sicherheitsaspekten und dem Fokus auf „Enterprise“-Anwendungen welche Eran Hammer in seinem Artikel erwähnt, hat mich die Fehlende Interoperability von OAuth 2 zuerst am Meisten genervt:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Mein erster Gedanke: Na toll! Man macht sich hier Gedanken über dezentrale Netzwerke, für die man einfache und simple Spezifikationen braucht und Familie OAuth released ein „Framework“…

Aber eigentlich ist ja gerade das auch eine riesen Chance für das Web! Während OpenID Connect bestimmt, dass jeder Provider die komplette Spezifikation implementieren muss:

The OpenID Connect Basic Client profile only documents Clients using the Code Flow. OpenID Providers MUST support both flows. OpenID Providers should consult the OpenID Connect Standard 1.0 Specification.

bleibt es jedem frei gestellt welchen Teil von OAuth 2 er umsetzt… Also warten wir doch einfach ab, bis das „Framework“ fertig ist, suchen uns die für das Web eleganteste Variante raus, dokumentieren sie schön und fertig ist „OAuth 2 – The Web Edition„.

…nicht perfekt, aber es könnte auch schlimmer sein!

openid-complex

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:

  1. Hol dir über folgende URL einen Access-Token:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL
  2. 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
  3. 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…