OAuth, OpenID und SSO … kann man das essen?

SSO ist überall und gefühlt jeder will es haben aber … was ist SSO eigentlich und was haben OAuth und OpenID damit zu tun?

Ich bin seit mehreren Jahren Berater (oder Senior Consultant) bei der blecon.
Insbesondere bei der Frage nach Digitalisierung von Unternehmen und der Vernetzung bestehender Infrastrukturen kommt das Thema SSO regelmäßig auf.
Aber auch bei der Entwicklung und Planung neuer IT Landschaften ist die Berücksichtigung von Access Management und der Nutzungserfahrung ein wichtiger Punkt um Akzeptanz mit einer neuen Lösung zu erreichen.

Was ist Single Sign On?

Fangen wir aber erstmal vorne an, was ist eigentlich SSO (oder Single Sign On)?

Zusammengefasst bedeutet Single Sign On, dass ein Benutzer sich nicht bei jedem einzelnen Dienst anmelden muss. Stattdessen erfolgt die Anmeldung immer über einen zentralen Dienst. Dieser Dienst, als Identity Provider (IDP, zu Deutsch Identitätsanbieter) bezeichnet, verwaltet die einzelnen Anmeldeinformationen aber auch Berechtigungen innerhalb der IT Infrastruktur.

Ein weit verbreitetes Bespiel, das in den letzten Jahren immer mehr Verwendung gefunden hat, ist beispielsweise das Entra ID von Microsoft. Durch die stark vorangetriebene Migration von lokalen IDPs, wie dem In-House betriebenen Active Directory Server, hin zu hybriden Lösungen oder gar vollständig in die Cloud verlagerten Szenarien, hat die Verwendung von SSO Optionen im Geschäftlichen Umfeld stark zugenommen.

Im privaten Umfeld war das Prinzip schon deutlich länger in einem verbreiteten, öffentlichen Einsatz möglich. Hier werden die IDP Schnittstellen oft von Anbietern von E-Mail-Konten oder von sozialen Netzwerken angeboten. Die Öffnung von privaten IDPs von Unternehmen ermöglicht es jetzt aber auch, dass diese für extern betriebene Dienste (SaaS Lösungen und ähnliches), verwendet werden können.

Wie funktioniert Single Sign On?

Der Einfachheit halber bleiben wir hier im Webumfeld. SSO ist grundsätzlich auch für Desktop und mobile Anwendungen nutzbar, das Konzept ist aber nahezu identisch und erfordert nur ein paar wenige, Platform und Use-Case abhängige Anpassungen.

Grundsätzlich gibt es 3+1 Ansätze, um SSO zu realisieren. Fangen wir mit dem +1 an, da ich persönlich das nicht unbedingt als wirklichen SSO Ansatz sehe. Ein Passwortmanager. Eine lokale Lösung, die es mit einer einmaligen Anmeldung erlaubt einfach und mit wenig Umstand auf andere Dienste zuzugreifen. Per Definition wäre das ein SSO Ansatz aber ohne viele der anderen Vorteile, wie einer zentralen Verwaltung und einer erhöhten Sicherheit.

Zwei weitere Ansätze sind die Portallösung und das Ticketing System. Die Portallösung erlaubt die Anmeldung an einem Portal und die Nutzung mehrerer dahinter liegender Dienste. Dies war vor allem früher ein verbreiteter Ansatz und ist heute noch vom Gefühl bei diensten wie Google zu finden. Mit einer Anmeldung auf einem der Portal-Zugänge sind die Anwendungen hinter den anderen Zugängen auch verwendbar. Das Ticketing System ist ein von vielen bereits benutztes aber nur wenigen bekannten SSO Verfahren. Eine bekannte Implantation von SSO Ticketing ist das so genannte Kerberos Protokoll. Dieses Protokoll wird vom klassischen In-House Active Directory Server verwendet. Ticketing erfordert einen bekannten, vertrauten Kreis von Diensten – daher bewegt es sich nur sehr selten auf die WAN-Seite der Firewall.

Die letzte Ausprägung von Single Sign On Möglichkeiten und die mit der wir endlich zu den anderen zwei Buzzwords im Titel kommen, ist ein Token basiertes Single Sign On.

Was sind Tokens?

Ein Token, in seiner simpelsten Ausprägung, funktioniert wie ein Passwort (und ist auch so zu behandeln!).

Ein Token ist eine oft zeitlich beschränke Zugangsberechtigung. Klassische Tokens sind oft nur lange, zufällige Zeichenketten die vom Nutzer an den Dienst oder vom Dienst an eine API übergeben werden und dort geprüft werden. Ein Nachteil: Die Gegenstelle muss den Token kennen, oder sich mit dem IDP, welches den Token generiert hat, unterhalten um ihn verifizieren zu können.

OAuth zur Tokenakquise

OAuth beziehungsweise OAuth in der Version 2.0 – OAuth2 – ist ein Protokoll zur sicheren Autorisierung und Authentifizierung von Nutzern an Ressourcen. Das OAuth2 Protokoll schafft einen Standard, mit dem sich der Nutzer mit dessen Nutzernamen und Passwort anmelden kann, ohne dass ein dritter Dienst, an dem sich authentifiziert werden soll, darauf Zugriff erhält.

In einem simplen Beispiel mit Webseiten im Browser funktioniert dass dann so

• Ein Benutzer besucht den Dienst, den er oder sie benutzen möchte.
• Unser Nutzer klick auf „Anmelden“ und wählt unseren Identity Provider dafür aus.
• Als nächstes wird der Nutzer von unserem Dienst zu unserem Identity Provider weitergeleitet.
  Hierbei werden Informationen mit übermittelt, die unseren Dienst gegenüber unserem IDP kennzeichnet.
• Unser IDP und der Nutzer haben nun drei mögliche Zustände miteinander
  • Unser Nutzer ist neu bei unserem IDP und muss sich erstmalig registrieren
  • Unser Nutzer ist nicht eingeloggt und tut dies mit dessen Nutzername und Passwort
  • oder unser Nutzer ist bei unserem IDP durch eine aktive Browser-Session oder Cookies angemeldet
• Das heißt jetzt wissen wir, wer unser Nutzer ist, wir könnten im IDP prüfen, ob dieser Nutzer überhaupt berechtigt ist auf unseren Dienst zuzugreifen
• Wir leiten unseren Nutzer nun zurück zu unserem Dienst und liefern den Token dabei mit
• Jetzt haben wir unsern Nutzer und einen Zugriff der uns im Hintergrund als dieser Nutzer authentifiziert und es uns erlaubt mit deren Autorisierung zu handeln

Und was ist mit OpenID?

Je nach dem, welche Art von Token wir übermitteln müssen wir von unserem Dienst aus jetzt diesen Token beim IDP verifizieren (oder wir versuchen ihn einfach zu nutzen und sehen, was passiert) oder wir nutzen ein „intelligentes“ Token Format wie JSON Web Tokens, welches es uns erlaubt den Token basieren auf einer Signatur direkt zu prüfen, ohne zusätzliche Kommunikation. Wie wir einen solchen ID-Token erhalten unterscheidet sich nicht zu den vorherigen Schritten, da OpenID zur Tokenakquise den OAuth2 Standard verwendet.

Wenn wir eine JWT (einen JSON Web Token) verwenden dann haben wir es sehr wahrscheinlich schon mit OpenID zu tun. OpenID erweitert unseren einfachen, „dummen“ Token um Informationen über den Nutzer. Durch den JWT, der es uns erlaubt tatsächlich Informationen in diesen so genannten ID-Token einzubetten, können wir Grundinformationen wie zum Beispiel einen Anzeigenamen aber auch Berechtigungen direkt im Token übertragen. Durch die Signatur des Tokens sind die darin enthaltenen Daten von Manipulation geschützt und wir müssen nicht zusätzlich mit dem Identity Provider sprechen, um die tatsächliche Autorisierung unseres Benutzers zu erfahren. Wir wissen durch den ID-Token bereits, ob der Nutzer zum Beispiel Einträge in unserem System anlegen darf oder nur lesend berechtigt ist.