You shall not pass! (1/2) - Die Magie hinter SAML und OpenID Connect

Egal, ob beim Bedienen der Suchmaschine, dem Einkauf bei großen Onlinehändlern oder während des Vernetzens mit Freunden: Single-Sign-on (SSO) Solutions ermöglichen die Verwendung eines einzelnen Accounts für viele Anwendungen überall im Internet.

Auch in Unternehmen ermöglicht SSO eine nahtlose Authentifizierung der Mitarbeitenden. Wie die Protokolle dahinter funktionieren und was Sie bei der Auswahl für Ihre SSO-Lösung beachten sollten, erfahren Sie in dieser Blogreihe. Dieser Artikel nimmt Sie mit auf einen Deep-Dive zum Thema OpenID Connect. 

Mit OpenID Connect zur SSO Solution

Im Homeoffice noch schnell im Intranet den nächsten Urlaub beantragen, dann ein Wechsel zum Kalender-Tool und anschließend in die Cloud. Sich jedes Mal neu anzumelden, war gestern. Mit SSO reicht ein einzelner Login aus. Doch wie funktioniert das genau?

Jede Anwender, der sich in einem solchen System einloggen möchte, braucht zunächst eine Identität. Eine digitale Identität ist eine Behauptung über sich selbst oder ein anderes digitales Element. Diese Behauptung enthält verschiedene identitätsbezogene Daten, sogenannte Claims. Ein Claim kann ein Name oder eine E-Mail-Adresse sein, aber auch Gruppen beinhalten, die eine Position im Unternehmen widerspiegelt. Eine Identität ist also eine zusammengehörende Menge an Claims. Diese wird typischerweise von einem Identity Provider bereitgestellt. Identity Provider können Tools wie Keycloak, Microsoft AD oder Hashicorp Vault sein.

Der erste Schritt eines Logins ist die Identifikation. Die Identifikation ist eine Behauptung, der Inhaber eines Benutzernamens oder einer ID zu sein. Sie allein sagt noch nichts darüber aus, ob die angegebene Identität korrekt ist. Dies passiert erst im zweiten Schritt, der Authentifizierung. Dabei wird die Identität des Benutzers mit einem Passwort oder einem Sicherheitsschlüssel überprüft. Ist ein Nutzer authentifiziert, wird eine Autorisierung (eine Freigabe) benötigt, damit auf eine Ressource zugegriffen werden kann. 

OAuth und OpenID Connect

OpenID Connect (OIDC) wird an vielen Stellen im selben Atemzug mit OAuth erwähnt. Auch wenn diese beiden Protokolle miteinander verwandt sind, sind sie nicht synonym zu verwenden.

Während OAuth für Autorisierungen genutzt werden kann und eigentlich ein Framework ist, ist OpenID Connect eine Authentifizierungsschicht auf Basis von OAuth. OAuth ist also die Basis für eine Autorisierung (eine Freigabe) während OpenID Connect den Nutzer authentifiziert (die Identität überprüft). Um das gesamte Konzept von OpenID Connect zu verstehen, werden wir im Folgenden zunächst OAuth betrachten.

Das OAuth Framework definiert vier Rollen, die später von OpenID Connect ausgefüllt werden:

• Der „Resource Owner“ ist die Instanz, die in der Lage ist, Zugriff auf eine geschützte Ressource zu gewähren. Ist der Resource Owner eine Person, so ist dies der Endnutzer, also beispielsweise ein Mitarbeiter.
• Der „Resource Server“ ist der Server, auf dem die geschützte Ressource liegt.
• Ein „Client“ ist eine Anwendung, die im Namen des „Resource Owners“ auf Ressourcen zugreift. Ein weiterer Name ist auch Relying Party.
• Der „Authorization Server“ stellt dem Client ein Zugriffstoken aus, sobald der „Resource Owner“ authentifiziert ist und den Client autorisiert hat. Diese Rolle übernimmt der Identity Provider in OpenID Connect.

Ein grundsätzliches Zusammenspiel der Komponenten von OAuth ist in der folgenden Grafik zu erkennen.

Authentication Flows in OAuth und OpenID Connect

Eine Authentifizierung mit OAuth (und auch OpenID Connect) kann unterschiedlich durchlaufen werden. Diese Abläufe bezeichnet man auch als Flow. In der OAuth 2.0 Spezifikation werden fünf Möglichkeiten aufgelistet, wie eine Authentifizierung erfolgen kann:

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Credentials Grant
• Client Credentials Grant
• Extension Grants

Im Entwurf der neuen OAuth 2.1 Spezifikation wird diese Liste abgeändert. Der Refresh Token Grant wird neu hinzugefügt und der Implicit Grant sowie der Resource Owner Password Credentials Grant werden entfernt.

Der Authorization Code Grant Flow ist der Flow, welcher in den meisten Fällen für die Authentifizierung mit OAuth und auch OpenID Connect verwendet werden sollte.

Der Ablauf des Authorization Code Grant Flow ist in der oben eingefügten Grafik zu erkennen und besteht aus den folgenden Schritten:

1. Der Resource Owner wird zunächst vom Client an den Authorization Endpoint des Authorization Servers weitergeleitet. Außerdem werden Informationen vom Client über sich selbst mit in die Anfrage eingefügt. Diese enthalten beispielsweise einen Client-Identifier, ein Scope und eine Redirect URL.
2. Der Besitzer der Ressource muss sich gegenüber des Authorization Servers authentifizieren. Weiter muss dieser den Client autorisieren, die angefragte Ressource verwenden zu dürfen. Manche Tools, wie beispielsweise Keycloak, bieten die Möglichkeit, die Clients so einzurichten, dass eine explizite Autorisierung durch den Besitzer nicht mehr erforderlich ist. Dies bietet sich vor allem für Mitarbeitende im Unternehmenskontext an.
3. Ist der Besitzer authentifiziert und der Client autorisiert, so sendet der Authorization Server den Ressource Owner zurück zur Redirect URL, welche vom Client im ersten Schritt mit in der Authorization Request gesendet wurde. Hierbei fügt der Authorization Server seiner Antwort einen Code hinzu. Dieser Authorization Code verleitet dem Authorization Code Grant Flow seinen Namen.
4. Den Authorization Code kann der Client am Token End-Point gegen ein Access Token eintauschen. Zuvor muss sich der Client mit seiner ID und einem Secret authentifizieren. Diese sind zuvor manuell oder über die dynamische Client Registration eingerichtet worden. Außerdem muss der Client die Redirect URL angeben, welche im ersten Schritt mit angegeben wurde. Diese Kommunikation findet direkt zwischen Client und Authorization Server statt und läuft nicht über den Resource Owner.
5. Der Authorization Server authentifiziert den Client und prüft den Authorization Code sowie die Redirect URL. Ist der Client autorisiert, so reagiert der Authorization Server mit einem Access Token für den Ressourcen-Zugriff und optional mit einem Refresh Token zum Verlängern des Access Tokens.

Der Implicit Grant Flow wird zwar noch häufig verwendet, allerdings ist dies für die neuen Anwendungen nicht mehr sicher genug. Der Grund dafür ist die direkte Übertragung des Access Tokens über den Owner anstelle eines Authorization Codes. Dadurch ist der Client anfälliger für gefälschte Access Tokens.

Die anderen Variationen werden in der Praxis seltener verwendet und werden deshalb im Folgenden nicht weiter erläutert.

Scopes und was OpenID Connect von OAuth unterscheidet

In OAuth ist ein Scope wichtiger Bestandteil jeder Authorization Request. Das Scope gibt an, welche Inhalte und welcher „Umfang“ die Antwort haben soll. Also beispielsweise, auf welche Ressourcen zugegriffen werden darf und ob der Zugriff auf die Ressource nur lesend oder auch schreibend gegeben ist. Das Scope wird vom Authorization Server ausgewertet und weiterverwendet, um das Access Token zu erstellen.

Betrachtet man den Ablauf von OAuth, unterscheidet sich zunächst nur das gesetzte Scope zwischen OAuth und OpenID Connect. In OpenID Connect enthält dieses immer den Wert „openid“. Weitere optionale Scopes sind „profile“, „email“, „address“ und „phone“, welche dazugehörige Claims anfordern. Identity Provider bieten in der Regel auch die Möglichkeit, eigene Scopes zu erstellen.

Ein geändertes Scope ist allerdings nicht der einzige Unterschied zwischen OAuth und OpenID Connect. Auch der Response Type wird um den optionalen Wert „id_token“ erweitert. Ist „id_token“ gesetzt, so wird ein JWT Token (ID-Token) mit den Claims aus dem Scope, zusammen mit dem Access Token, zurück an den Client gesendet. Wie sich dies in den Ablauf bei einem Authorization Code Grant auswirkt, sehen Sie in der Abbildung 3. 

Neben dem ID-Token bietet OpenID Connect neue Endpoints auf dem Identity Provider. Am Userinfo-Endpoint kann der Client sein Access Token nutzen, um mit diesen Informationen über den User zu erhalten. Mit dem Logout Endpoint implementiert OpenID Connect einen zentralen Logout, der durch den Client ausgelöst werden kann.

Weiter setzt der OpenID Connect Standard die Art des Access Tokens fest. Während das OAuth Framework nur definiert, dass ein Access Token ein String sein muss, wird diese Definition in OpenID Connect spezifiziert. Ein Access Token in OpenID Connect muss ein auch bei OAuth häufig verwendetes JWT Tokens sein. Wie so ein JWT Token in OAuth genutzt werden kann, erfahren Sie im Artikel „Rest-Schnittstellen absichern mit Java Spring, OAuth2.0 & JSON Web Token“. 

Fazit

In diesem Teil haben Sie einen tieferen Einblick in OpenID Connect gewonnen. OpenID Connect ist eine Authentifizierungsschicht, die auf dem bewährten OAuth-Framework aufbaut. Sie haben die verschiedenen Komponenten von OpenID Connect kennengelernt, und einen Blick auf den Ablauf des Authorization Code Grant Flow geworfen. Sie wissen jetzt, dass es mit OpenID Connect neue Endpunkte und ein ID-Token gibt, das Sie für die Authentifizierung nutzen können. Mit diesem technischen Verständnis sind Sie nun bereit, eine OpenID Connect-basierte Single-Sign-on (SSO) Lösung in Ihrem Unternehmen zu implementieren.

OpenID Connect ist nur eine Möglichkeit, um SSO in einem Unternehmen umzusetzen. Im nächsten Kapitel dieser Blogreihe stellen wir Ihnen das XML-basierte Protokoll SAML vor. 

Seminarempfehlung