OpenID Connect: Login mit OAuth, Teil 1 – Grundlagen

Inhaltsverzeichnis

OAuth 2.0 hat sich als Standard für die Autorisierung von API-Zugriffen im Web etabliert. Wer es auch zum Login einsetzen wollte, war bisher auf anbieterspezifische Erweiterungen angewiesen. Mit OpenID Connect gibt es jetzt einen neuen Standard, der OAuth 2.0 um alle notwendigen Funktionen für Login und Single Sign-On erweitert.

Da OpenID Connect als Erweiterung von OAuth 2.0 konzipiert ist, profitiert es von dessen grundlegenden Eigenschaften, zum Beispiel Einfachheit, Sicherheit und Unterstützung diverser Klassen von Anwendungen – von Web-Portalen bis hin zu Apps auf diversen Endgeräten. Durch die Integration des Logins in OAuth wird es darüber hinaus möglich, mit demselben Protokoll kombinierte Szenarien, also das Login im Namen des Benutzers und den abgesicherten Zugriff auf dessen Ressourcen, zu implementieren. Dafür waren bisher Hybridprotokolle wie Googles Hybrid aus OpenID 2.0 und OAuth erforderlich.

OpenID Connect wurde am 26. Februar 2014 als Standard der OpenID Foundation verabschiedet und ist bereits von Anbietern wie Google, Microsoft und der Deutschen Telekom implementiert worden. Zwei Artikel erläutern das Protokoll und zeigen anhand von Beispielen, wie sich unterschiedliche Anwendungsfälle verschiedener Komplexitätsstufen implementieren lassen. Dabei greift der Autor auf Erfahrungen aus der Implementierung des Protokolls bei der Deutschen Telekom zurück. Im ersten Artikel stehen die Grundlagen im Fokus, der zweite behandelt weiterführende Themen wie die Integration von unterschiedlichen Identitätsprovidern in eine Anwendung und fortgeschrittene Steuerungsmöglichkeiten für den Login-Prozess. Es werden Kenntnisse des unterliegenden Protokolls OAuth 2.0 vorausgesetzt. Hierfür sei auf den Vorgängerartikel zu OAuth 2.0 verwiesen.

Der Blick zurück

Wer bisher Single Sign-On (SSO) zwischen den Portalen eines Anbieters oder eine ID-Föderation zwischen Webportalen und Apps unterschiedlicher Anbieter auf standardisierte Art und Weise implementieren wollte, hatte die Wahl zwischen OpenID 2.0 und SAML 2.0 (Security Assertion Markup Language). Obgleich OpenID 2.0 ein relativ einfaches Protokoll ist, hat es einige Schwächen im Bereich der Sicherheit. Außerdem ist der limitiert, sodass der Einsatz in etwas anspruchsvolleren Szenarien Erweiterungen erfordert. SAML 2.0 hingegen ist ein sicheres und mächtiges Protokoll, das einige Applikationsserver direkt unterstützen. Es krankt allerdings an der inhärenten Komplexität des unterliegenden Standards für XML-Signaturen und hat sich im Betrieb aufgrund der Verwendung von X.509-Zertifikaten als schwer zu beherrschen herausgestellt. Dass beide Protokolle nicht auf die Erfordernisse moderner Apps ausgelegt sind, überrascht nicht, schließlich entstanden sie vor deren Erfindung (2007 bzw. 2005).

Gleichzeitig hat sich OAuth 2.0 im Verlaufe der letzten Jahre als Standard für die Absicherung des Zugriffs auf alle Arten von APIs im Internet durchgesetzt. Da der OAuth-Prozess in der Regel auch mit einem Login des Benutzers einhergeht, erscheint es für immer mehr Dienstanbieter naheliegend, OAuth auch für das Login einzusetzen. OAuth ist eine einfache und sichere Basis, die zudem zeitgemäße Anforderungen wie die Unterstützung von Apps auf Smartphones oder Smart-TVs erfüllt.

Allerdings fehlen OAuth als Autorisierungsprotokoll einige für das Login wichtige Fähigkeiten: Zum einen stellt der OAuth-Autorisierungsserver dem Client (bewusst) keine Benutzer-ID oder andere Benutzerdaten zu Verfügung. Des Weiteren fehlen Funktionen zur Beeinflussung des Authentifizierungsprozesses (z. B. zum Erzwingen eines Logins) und zur gesicherten Übertragung von Informationen zum Authentifizierungsprozess (bspw. Zeitpunkt und verwendete Authentifizierungsmethoden).

Einige Dienstanbieter wie Facebook und Amazon haben daher für den Zweck des Logins proprietäre OAuth-Erweiterungen implementiert. Dabei wird in der Regel ein OAuth Access Token verwendet, um die eigentlichen Benutzerdaten von einer User Profile API abzufragen. Diese APIs sind aber leider nicht interoperabel. Darüber hinaus birgt die Vorgehensweise auch ein Sicherheitsrisiko. Letztlich kann jeder, der in den Besitz eines passenden Access Token gelangt, sich mit diesem bei allen angeschlossenen Anwendungen im Namen des betreffenden Benutzers einloggen. Der Angriff kann hierbei zum Beispiel von einer Anwendung ausgehen, in die sich der Benutzer eingeloggt hat. Der Betreiber dieser App kann das Token seinerseits verwenden, um sich an einem anderen Gerät in eine oder mehrere andere Apps im Namen des legitimen Benutzers einzuloggen. Das ist möglich, da die Gültigkeit dieses Access Token nicht auf eine bestimmte (Client-)Anwendung, sondern nur auf die User Profile API des Dienstanbieters eingeschränkt ist. Diese Art von Angriffen bezeichnet man
gemeinhin als Substitutionsangriff.