Seite 3: Exkurs zu OAuth 2.0 und OpenID-Connect

Inhaltsverzeichnis

Exkurs zu OAuth 2.0 und OpenID-Connect

Inzwischen liegt die Version 2.0 (Draft) von OAuth vor und gleichzeitig unterstützen einige Service-Provider (Google, Facebook und Twitter) Teile dieser Spezifikation. Der Schwerpunkt der neuen Entwicklung ist die Vereinfachung des Protokolls sowie die Bereitstellung neuer Nutzungsszenarien (siehe auch Using OAuth 2.0 to Access Google APIs und Introducing OAuth 2.0).

Bisher war unter anderem die Integration von OAuth 1.x in eigene Anwendungen problematisch (vergleiche das Beispiel im Artikel Autorisierungsdienste mit OAuth auf heise Developer). Ohne OAuth 1.x war es möglich, mit einem einzigen GET-Befehl einen Serviceaufruf auszuführen. Hier mit dem Nachteil, dass Benutzername und Passwort anzugeben waren. Nach der Einführung von OAuth 1.x braucht man für den gleichen Zugriff auf einen Service meistens eine OAuth-Client-Bibliothek, ein einzeiliger GET-Befehl geht nicht mehr.

Nun hat die Entwickler-Community den Wunsch geäußert, einen einfachen Zugriff ohne Eingabe eines Benutzernamen und Passwortes ermöglichen zu können. Zudem sei das Signieren einer Anfrage für viele Entwickler viel zu kompliziert. Abhilfe schafft das jetzt eingeführte "Bearer Token". Das Konzept erlaubt es, mit einem einfachen GET-Befehl einen unsignierten Service-Zugriff über HTTPS durchzuführen. (Das Konzept der Bearer Token gab es schon in OAuth 1.0a, es wurde jedoch nicht als explizite Option erwähnt und ihm daher keine wichtige Rolle zugeteilt.) Mit den durchgeführten Vereinfachungen geht OAuth 2.0 sicherlich in die richtige Richtung, allerdings gehen auch Gefahren mit dem neuen Mechanismus einher.

OAuth 2.0 soll zudem zusätzliche Anwendungsfälle (bekannt als "Flows", Szenarien zur Abholung von Zugriffstoken) unterstützen: OAuth 1.x verstand sich ursprünglich mit Web-, Desktop- und Mobil-Anwendungen. Im Endeffekt liefert die OAuth-1.x-Spezifikation jedoch nur ein einziges Szenario mit drei unterschiedlichen Client-Anwendungstypen. Für Webanwendungen ist das benutzerfreundlich genug, doch für Desktop- oder gar Mobil-Anwendungen ist es zu wenig, da es dort an einer guten Benutzerführung fehlt. Dies ändert sich jetzt mit OAuth 2.0, das gleich mehrere Anwendungsfälle unterstützt:

• User-Agent-Szenario: Geeignet für Konsumentenanwendungen, die in einem Webbrowser laufen, ein Beispiel sind JavaScript-Anwendungen.
• Webserver-Szenario: Geeignet für Konsumentenanwendungen, die auf einem Webserver laufen und auf die per HTTP-Anfrage zugegriffen werden kann. Dieses Szenario entspricht dem bisher bekannten OAuth 1.0 in vereinfachter Form.
• Device-Szenario: Dieses Szenario ist für mobile Geräte geeignet.
• Benutzername-und-Passwort-Szenario: Die Kombination aus Benutzername und Passwort ist die Basis für das Vertrauen zwischen Konsumentenanwendung und Benutzer. Das Szenario eignet sich für Betriebssysteme, das heißt, dass der Benutzername und das Passwort bei der Anfrage des Zugriffstoken mit verschickt werden.
• Client-Credentials-Szenario: Das Szenario entspricht dem bisher bekannten OAuth 1.0 in der Form eines zweigliedrigem OAuth.
• Assertion-Szenario: Die Konsumentenanwendung verwendet eine SAML-Assertion (Security Assertion Markup Language), um ein Zugriffstoken zu bekommen.

Inzwischen haben sich die Ablaufdefinitionen geändert, nähere Informationen dazu in der derzeit aktuellen Spezifikation.

Letztlich verspricht OAuth 2.0 auch eine bessere Performanz und Aufgabenverteilung: Die Stellen, an denen die Anfrage- und Zugriffstoken angefordert werden können, sind in zwei Bereiche unterteilt, was eine klarere Trennung der Zuständigkeiten erlaubt.

Im Prinzip stellt OAuth 2.0 eine Weiterentwicklung des bisherigen Protokolls dar. Für die Implementierung stehen derzeit noch wenige fertige Bibliotheken zur Verfügung, erwähnenswert für Java-Entwickler ist das Framework Spring Social mit OAuth 2 (ausschließlich als Framework "für OAuth-Konsumenten") und das Framework Spring Security mit OAuth 2 (sowohl als OAuth-Konsumenten- wie auch OAuth-Service-Provider-Framework).

Zu OpenID-Connect existiert derzeit eine einzige Website. Das System sollte als "die nächste Generation von OpenID" fungieren und beruht komplett auf OAuth 2, auf dessen Grundlage die Spezifikation von OpenID-Connect fußt. Der Kopf hinter dieser Entwicklung ist David Recordon, von Anfang an in die OpenID-Spezifikation involviert. Seine Idee beruht auf der Tatsache, dass OpenID 1.x teilweise komplex und schwierig zu implementieren sei. Sämtliche OpenID-Abläufe sollten auf OAuth-2-Abläufen aufbauen, wozu man einen OAuth-Scope namens openid angibt. Generell sollen später sämtliche anderen OpenID-Mechanismen über das Scope-Konzept abgebildet werden – die weitere Entwicklung von OpenID-Connect bleibt daher spannend.