Moderne Web-Anwendungen bestehen meistens aus einem Backend, einem Frontend und zu guter Letzt einer Prise OIDC. OIDC ist in diesem Umfeld der gängigste Standard zur sicheren Authentifizierung und sollte daher von jedem Web-Entwickler verstanden werden. Dieser Beitrag gibt einen grundlegenden Überblick über das Authentifizierungs-Protokoll und dessen Bedeutung mit Fokus auf die Softwareentwicklung.
Was ist OpenID Connect?
OpenID Connect (kurz OIDC) ist ein offenes Protokoll, das zur Authentifizierung von der OpenID Foundation definiert wurde. Es basiert auf dem offenen Protokoll OAuth2, welches zur Autorisierung dient. Es ergänzt dieses um die Verwaltung von zusätzlichen Benutzerinformationen, beispielsweise dem vollen Namen oder der E-Mail-Adresse. Vereinfacht ausgedrückt dient OIDC zum Beweis der Identität, während OAuth2 die Berechtigungsverwaltung in den Fokus stellt.
Im Wesentlichen besteht OIDC aus sogenannten Flows, welche jeweils ein vollständiges Verfahren zur Authentifizierung beschreiben. Um die Sicherheit der Anwendung nicht zu gefährden, ist es entscheidend, den richtigen Flow auszuwählen. Dies hängt vor allem von der Art der Anwendung ab. Dabei ist z. B. wichtig, ob es sich beispielsweise um eine Single Page Application (SPA) oder um ein Backend handelt. Am Ende eines Flows ist es entscheidend, einen vom Identity Provider signierten Token zu erhalten, der die Identität des Benutzers nachweist.
Der Identity Provider ist meist für mehrere Anwendungen zuständig, lässt sich zentral verwalten und verantwortet die Benutzerinformationen inklusive der Passwörter. Dadurch liegt dieser sensible und sicherheitskritische Bereich nicht in der Verantwortlichkeit von OIDC und der Anwendungen, die es verwenden. Außerdem werden so die Möglichkeiten zum Single Sign On (SSO) erheblich vereinfacht, da es eine global genutzte Authentifizierungsstelle gibt.
Jeder Identity Provider hat seine Vor- und Nachteile, auf die in diesem Artikel nicht näher eingegangen wird. Aus OIDC-Protokollperspektive bzw. Client-Perspektive macht dies aber keinen Unterschied, solange sich der Hersteller an den offenen Standard hält.
Überblick über die OIDC-Flows
OIDC (in Kombination mit OAuth2) definiert die folgenden Flows:
- Authorization Code Flow
- Implicit Flow
- Hybrid Flow
- Resource Owner Password Flow
- Client Credentials Flow
Wichtig ist, dass alle Flows ihre Vor- und Nachteile haben. Die Architektur- und Sicherheitsanforderungen sind maßgeblich für die Auswahl des korrekten Flows. Während sich der Resource Owner Password Flow hervorragend zum Debuggen bestimmter Spezialfälle eignet, stellt der Client Credentials Flow ein Autorisierungsverfahren zwischen zwei Backend-Systemen dar. Diese beiden Flows sind primär im OAuth2 Layer definiert.
Der Authorization Code Flow, Implicit Flow und Hybrid Flow eignen sich hingegen zur Authentifizierung von Benutzern über ein Frontend. Das Grundprinzip dieser Flows ist ähnlich. Ein Frontend (z. B. eine SPA) initiiert dabei das Verfahren. Dazu leitet es den User im Browser zum Identity Provider weiter und schickt dabei alle für den Flow notwendigen Parameter mit. Nach der Weiterleitung zeigt der Identity Provider dem User eine Anmeldeseite an. Nachdem sich dieser erfolgreich angemeldet hat, erfolgt eine Weiterleitung vom Identity Provider zurück zum Frontend. Die Informationen, die dabei als Parameter mitgesendet werden, kann das Frontend nutzen, um eine erfolgreiche Anmeldung zu beweisen.
Die meisten Flows können in verschiedenen Ausprägungen implementiert werden und sind daher nicht immer exakt identisch eingerichtet. Beispielsweise gibt es für den Authorization Code Flow eine Erweiterung „PKCE“ (Proof Key for Code Exchange), die die Sicherheitsstandards weiter erhöht.
Achtung: Der Implicit Flow gilt als unsicher und sollte daher nicht mehr verwendet werden. Zum Einarbeiten in das Thema der Authentifizierung ist es aber dennoch lehrreich, ihn zu betrachten.
Warum ist OIDC für Web-Entwickler wichtig?
Da das Thema Authentifizierung im Allgemeinen in nahezu jeder Anwendung eine Rolle spielt, gehört es zu den grundlegenden Themen, mit denen sich ein Softwareentwickler auskennen sollte. Das Internet liefert zwar eine Fülle von Tutorials und Codebeispielen, jedoch sollte man diesen nicht blind vertrauen. Dies kann beispielsweise dazu führen, dass die Authentifizierung nur augenscheinlich funktioniert. Allerdings bedeutet dies nicht im Umkehrschluss, dass sie auch auf eine sichere Art und Weise implementiert wurde. Mit OIDC kann dieses trügerische Verhalten zustande kommen, wenn ein falscher Flow verwendet wird. Daher ist es wichtig, die „Best Practices“ zu kennen und zu wissen, auf welche Details zu achten ist.
Herausforderungen bei der Implementierung
Bei der Implementierung einer OIDC-Schnittstelle kann der Einsatz einer Library sehr hilfreich sein. Eine passende Library zu finden, gestaltet sich je nach Framework und Programmiersprache verschieden leicht. da die Qualität der Libraries sehr unterschiedlich ist. Inzwischen bieten auch die meisten Identity-Provider-Hersteller eigene Libraries an, allerdings kann dies dazu führen, dass man sich mit einem eigentlich offenen Protokoll stärker auf einen bestimmten Hersteller festlegt. Diese Entscheidung ist nicht grundsätzlich falsch, sollte aber entsprechend abgewogen werden.
Die meisten Libraries ermöglichen die Implementierung verschiedener OIDC Flows, wodurch eine sehr große Anzahl an Konfigurationsparametern zustande kommt. Hier ist sorgfältig darauf zu achten, dass auch tatsächlich der richtige OIDC Flow konfiguriert wird. Welcher das ist, hängt ein Stück weit von der jeweiligen Anwendungsarchitektur ab.
Eine weitere Herausforderung ist es, sicherzustellen, dass für alle beteiligten Softwareentwickler auch die Entwicklungsumgebungen weiterhin funktionieren. Dazu kann entweder die Authentifizierung lokal per „Featureflag“ deaktiviert werden, ein cloudbasierter oder ein lokaler Identity Provider, z. B. Keycloak, angebunden werden. Die Option eines lokalen Keycloaks hat SVA beispielsweise mit einem Codestart Bundle realisiert und somit zu einer guten wiederverwendbaren Lösung entwickelt. Die mit allen Lösungsansätzen verbundenen Vor- und Nachteile sind stets abzuwägen.
Zusammenfassung: Die wichtigsten Punkte im Überblick
An OIDC geht im Rahmen einer Webentwicklung kaum ein Weg vorbei. Dabei sollten folgende Punkte besondere Beachtung finden:
- OIDC ist ein offener Standard und weit verbreitet.
- OIDC basiert auf dem offenen Standard OAuth2.
- Kritische Informationen wie Benutzerpasswörter liegen in der Verantwortung des Identity Providers.
- OIDC kann augenscheinlich funktionieren, ist aber nicht automatisch sicher.
- Entscheidend ist es, den richtigen Flow zu implementieren.
- Der richtige Flow hängt von der Softwarearchitektur ab.
- Eine Library kann Herstellerabhängigkeiten schaffen.
Weiterführende Links
OpenID Connect Core 1.0 Spezifikation: https://openid.net/specs/openid-connect-core-1_0.html
OAuth 2.0 Authorization Framework Spezifikation: https://datatracker.ietf.org/doc/html/rfc6749