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!
[…] OAut(sc)h – notizBlog […]
Hoffen wir mal, dass das mit der „WebEdition“ auch klappt.
Was mich an diesen ganzen Auth Methoden stört, ist, dass es dazu immer einen Provider geben muss. Für mich wäre eine Version ideal, bei der sich jeder mit seiner eigenen Website authentisieren kann. Ich stelle mir das ungefähr so vor, dass ein User eine url und ein passwort eingibt. Der Service lädt das Dokument von der url. Definieren wir mal, das sei eine Webseite. Dann wird das Passwort gehasht (md5 oder sha oder sowas) und mit dem Passwort auf der Seite verglichen. bei Übereinstimmung ist es wohl der User. Dabei gehe ich davon aus, dass nur der Eigentümer einer Webseite diese auch entsprechend verändern kann.
Wie gesagt, mich stören immer diese „Provider“.
Ich finde übrigens folgende lightweight Authentifizierungsverfahren gerade ganz Spannend: Dialback oder das Domain Federation Protocol