Ein häufiges Argument gegen die Verwendung von Open-Source-Anwendungen ist, dass sie sich nicht nahtlos in die eigene IT-Struktur einbinden lässt und daher häufig mit einer eigenen Benutzerdatenbank daherkommt. Aus IT-Security-Sicht natürlich ein absolut unerwünschstes Szenario. Doch die Welt hat sich geändert!

Eigentlich wurde bereits 2006 mit OAuth ein Autorisierungsframework entwickelt, das es ermöglicht, als entfernte Anwendung einen zentralen Authentifizierungsprovider zu nutzen. Damals generierte das Framework kurzzeitig viel Aufsehen, verschwand dann aber relativ schnell wieder in der Versenkung. Mit den Jahren entdeckten mehrere große Serviceprovider wie Google oder Microsoft OAuth bzw. die darüber gelagerte Authentifizierungsschicht OpenID Connect als gutes Mittel, um innerhalb der eigenen Dienste eine einheitliche Anmeldung realisieren zu können. Spätestens mit Microsoft Azure AD (jetzt Microsoft Entra ID) erlangte OpenID Connect plötzlich wieder weltweite Beachtung.

Und so ist es nicht verwunderlich, dass es mittlerweile sehr unkompliziert geworden ist, eine Anwendung, die OpenID Connect unterstützt mit einem zentralen Authentifizierungsprovider von Google, Microsoft, AWS etc. zu verbinden. Doch wie funktioniert das?

1. Die Anwendung muss als Authentifizierungsmethode OpenID Connect anbieten. Zugangsdaten werden nun nicht mehr via Formular der Awendung selber übergeben, stattdessen besteht der Login aus einem Button oder Link, der den Nutzer zum Anwendungsprovider weiterleitet.
2. Die Anwendung authentifiziert sich dabei gegenüber dem Provider mittels ID und Schlüssel. Außerdem gibt die Anwendung mit, zu welcher URL der Nutzer nach erfolgreicher Authentifizierung geleitet werden soll und welche Nutzerdaten abgefragt werden sollen.

3. Stimmen alle vier Angaben mit den Daten, die im Provider hinterlegt sind überein, führt dieser den eigentlichen Login durch. Dem Nutzer ist das durch das typische Login-Fenster bekannt, wie im Screenshot gezeigt.

4. Ist die Authentifizierung erfolgreich, leitet der Provider den Nutzer zur Anwendung zurück und übergibt selbiger die angeforderten Nutzerstammdaten wie z.B. Benutzername, Vor- und Nachname oder E-Mail-Adresse. Welche Daten konkret eine Anwendung erhalten darf, kann in Form von scopes im Authentifizierungsprovider konfiguriert werden.

Welche Vorteile bringt diese Form der Authentifizierung?

Im Wesentlichen den, dass Anwendungen keine eigenen sensiblen Zugangsdaten mehr verwalten und speichern müssen, was das Risiko durch Angriffe drastisch reduziert. Anwendungen kommen zudem somit gar nicht mehr mit Benutzernamen und Passwörter in Kontakt, was ebenfalls zu einer Risikoreduktion beim Einsatz unbekannter Anwendungen beiträgt. Zuletzt ist es so möglich, die zentrale Nutzer-ID zum Login für alle Anwendungen einer Organisation zu nutzen, was dem Nutzer die Verwendung vieler unterschiedlicher Passwörter erspart.

Falls die eigene Organisation keinen öffentlichen Provider oder mehrere unterschiedliche Provider nutzt, können Dienste wie Keycloak oder Authentik dabei helfen, komplexere Szenarien zu realisieren.

Die Anwendungen, die wir bei server.camp anbieten, sind von uns sorgfältig getestet und erprobt. Ein wesentlicher Faktor dabei ist, ob OpenID Connect angeboten wird. Fast alle Anwendungen lassen sich daher mühelos integrieren. Falls du Fragen dazu hast, schreib uns gerne eine Nachricht!

Schreib uns!