Meine Vorgänger*innen haben bereits mehrfach auf die zunehmende Bedeutung der doppelten Authentifizierung zur Steigerung der Sicherheit im IAM-Bereich hingewiesen. Identity & Access Management (kurz IAM) geht aber noch weiter und wird durchaus innovativ. Ich möchte auf das Thema OpenID Connect (kurz OIDC) eingehen und die Möglichkeiten aufzeigen, wie unsere Daten noch leichter und sicherer übertragen werden können. Welche Vorteile bietet der OIDC-Dienst für mich als Endanwender?
Wichtiges vorab:
Was ist eine Authentifizierung und wo ist der Unterschied zu einer Autorisierung?
Ist es nicht ein und dasselbe?
Die Antwort ist: Nein, es sind zwei verschiedene Dinge. Bei einer Authentifizierung wird die Identität der Person überprüft und nachgewiesen, ähnlich wie beim Vorzeigen eines Personalausweises, bevor sie auf die geschützte Anwendung zugreifen darf. Auf digitalem Wege kann die Authentifizierung auf verschiedene Weise erfolgen:
- Einmalpasswort (engl. One Time Passcode (OTP))
- Digitale Zertifikate
- Authentifizierung der Geräte (Device Authentication)
- Biometrie (Fingerabdruck, Gesichtserkennung, FIDO-Key)
Bei der Autorisierung wird geprüft, ob der User berechtigt ist, auf die Anwendung zuzugreifen und ob es spezielle (auf den User bezogene) Berechtigungseinschränkungen gibt. Der User könnte zum Beispiel bestimmte Privilegien haben, wie den Administrator-Zugang oder die Aktivierung erweiterter Funktionalitäten. Andererseits kann die Autorisierung dazu verwendet werden, den Zugang auf ein Minimum zu beschränken.
OpenID Connect – Authentifizierung auf den Schultern von OAuth 2.0
Um OIDC zu erklären, musst du zunächst verstehen, wofür OAuth 2.0 verwendet wird.
OAuth 2.0 ist ein Autorisierungsprotokoll und damit die Grundlage von OpenID Connect (OIDC). Es ermöglicht einer Anwendung (App 1) den Zugriff auf die Daten des Users in einer anderen Anwendung (App 2), dem sogenannten Resource Server. Damit erhält App 1 die Berechtigung, im Namen des Users auf App 2 zuzugreifen. (Die App, die der User nutzen möchte, wird auch als „Relying Party“ bezeichnet, weil sie den Zugang zu einer sicheren Softwareanwendung bietet.)
Wenn App 2 also beispielsweise die Kontakte des Users einsehen möchte, kann sie diese von App 1 abrufen. Dies wird als delegierte Autorität bezeichnet. All dies geschieht, ohne dass der User der zweiten Applikation jemals ein Kennwort vorgelegt hat. Lediglich der Identitätsanbieter (= Identity Provider), bei dem der Nutzer registriert ist, kennt die Anmeldeinformationen des Users.
OAuth 2.0 löst das Problem der hochkritischen Offenlegung von Passwörtern. Ich melde mich in einer App mit meinen Benutzerdaten an und ein OAuth-Flow wird ausgelöst. Ohne Eingabe meines Passworts werde ich zur zweiten App weitergeleitet und authentifiziert, da diese Integration durch den Flow bestätigt wurde. Der Dienst von App 2 läuft im Hintergrund ab, während ich mich noch in App 1 befinde. Als Nutzer bekomme ich von dem schnellen Austauschprozess in der Regel nichts mit, abgesehen von der Frage nach meiner Zustimmung.
Das Besondere hieran: Ich als User kann steuern, wie viel App 2 an App 1 weitergeben darf (Level of Access). Zwischen den beiden Anwendungen wird ein sogenanntes „Access Token“, d.h. eine elektronische Berechtigungskarte, die auf den User bezogen ist, mit einem Access Level ausgetauscht. Als User habe ich die Kontrolle über die Zugriffsstufe, die ich der Drittanwendung gewähren möchte. Ich kann auch kontrollieren, über welchen Zeitraum die Anwendung auf welche meiner Daten zugreifen kann. Außerdem kann ich mein Passwort löschen, ohne die Integration zu zerstören. Wenn ich nicht möchte, dass die Drittpartei Zugriff hat, kann ich diese Verbindung jederzeit widerrufen. Mit anderen Worten: Ich habe die Macht, meine Daten sicher zu kontrollieren. Das ist mit delegierter Autorität gemeint.
OAuth 2.0 & OIDC im Zusammenspiel
OAuth 2.0 befasst sich also nur mit der Autorisierung, nicht mit der Authentifizierung. Hier kommt also OIDC ins Spiel:
Open ID Connect ist ein Authentifizierungsprotokoll, das Identity-Providern eine zusätzliche Benutzerauthentifizierung und Zugangskontrolle ermöglicht. Es ist ein Standard, der die OAuth 2.0-Autorisierung zusätzlich um den Schritt der Authentifizierung ergänzt, da er darauf aufbaut. So erhält die App 2 nicht nur den Schlüssel vom Identity Provider, sondern auch Informationen über die Identität des Nutzers. Dies ermöglicht es dem Nutzer, sich gleichzeitig bei mehreren Anwendungen anzumelden, bei denen er seine Identität nachweisen muss (soziale Medien, Profile auf Websites usw.).
Zusätzlich zum Access-Token wird ein benutzerspezifisches ID-Token generiert und ausgetauscht. Dieses signierte ID-Token wird im auf JSON-basierenden JWT-Format an App 2 übergeben und kann ausgelesen werden. Auf diese Weise kann App 2 nicht nur die Kontaktliste einsehen, sondern die Kontakte auch mit meinem Namen, meiner Stadt oder meiner E-Mail-Adresse verknüpfen, wenn ich dies erlaube.
Anwendungsbeispiele von OpenID Connect
Berühmte Beispiele für den OAuth 2.0- und OIDC-Flow ist die Nutzung der unterschiedlichsten Google-, Apple- und Microsoft-Dienste mit nur einem Login.
Wenn ich zum Beispiel bereits bei Google angemeldet bin, kann ich mein Profil bei einem der Google-Dienste wie YouTube verwenden. Nachdem ich YouTube die Erlaubnis erteilt habe, Informationen aus meinem Google-Konto abzurufen, kann ich alle meine abonnierten Kanäle sehen und bekomme Videovorschläge, die auf meinen Vorlieben basieren, ohne mich separat bei YouTube anmelden zu müssen. Mit nur einem Klick (Zustimmung) verbinde ich alle Google-Dienste miteinander. Dieses Prinzip funktioniert auf jedem Gerät.
Oder wer kennt sie nicht, die berühmte Lieferando-App? Um den Bezahlvorgang der hungrigen Kunden zu erleichtern, können sie sich ganz einfach mit ihrem Google-Konto anmelden. Google sendet den Namen und den Vornamen an die Anwendung, sodass sie sich den zusätzlichen Schritt der Registrierung auf Lieferando.de sparen können. Einfach und benutzerfreundlich.
- Der User möchte den Service von App 1 (Lieferando) nutzen, aber Lieferando weiß nicht, wohin die Pizzalieferung geschickt werden soll. D.h. der Name, die Zahlungsdaten, die Adresse, etc. werden benötigt.
- Lieferando fordert den User auf, sich bei Google zu authentifizieren.
- Google fragt den User um Erlaubnis.
- & 5. Wenn der User sein OK gegeben hat, wird ein Access-Token (= Schlüssel) von Google an Lieferando mit allen Informationen über den Kunden übergeben. Auf diese Weise kann der Bestellvorgang erfolgreich abgeschlossen werden.
Fazit
Der Vorteil der OIDC-Authentifizierungsprotokolle liegt auf der Hand: Ich spare meine wertvolle Zeit, indem ich mit wenig Aufwand auf mehr Anwendungen zugreifen kann. Das bedeutet, dass ich mich als Nutzer mehrerer Anwendungen nicht überall mehrfach anmelden und auch nicht alle meine Passwörter verwalten oder sie mir merken muss. Wenn ich einer Anwendung zu viel Macht gegeben habe, kann ich den Vorgang kontrollieren und den Zugriff oder den Abruf von Daten bei Bedarf widerrufen.
Es ist einfacher und sicherer, auf meine Online-Dienste zuzugreifen und sie zu nutzen – vor allem, seit die Nutzung von Social-Media-Plattformen zu einem festen Bestandteil unseres täglichen Lebens geworden ist.
Trotz der Vereinfachung der alltäglichen Authentifizierung und Autorisierung auf verschiedenen Plattformen solltest du auf jeden Fall darauf achten, dass keine App mehr Rechte als nötig hat. Achte darauf, welche Anwendung welche Einwilligungen hat und lies die oft lästigen Pop-up-Fenster zur Datenverarbeitung genau durch.
Wenn du OIDC in deiner Anwendung verwenden oder mehr über die technischen Details erfahren möchtest, kontaktiere uns – wir beraten dich gerne.
