Was ist OpenID Connect?

Moderne Anwendungen benötigen häufig nicht nur eine Möglichkeit festzustellen, was ein Nutzer tun darf, sondern auch, wer sich überhaupt angemeldet hat. Genau hier setzt OpenID Connect, kurz OIDC, an.

OIDC erweitert OAuth 2.0 um eine standardisierte Identitätsschicht. Während OAuth 2.0 in erster Linie die Autorisierung regelt – also beispielsweise, ob eine Anwendung auf eine bestimmte API zugreifen darf –, ergänzt OpenID Connect Informationen über den angemeldeten Nutzer.

Dadurch lassen sich Authentifizierung und Autorisierung klar voneinander trennen und trotzdem innerhalb eines gemeinsamen Standards abbilden. Für Anwendungen bedeutet das außerdem, dass die Anmeldung nicht individuell für jeden Dienst neu entwickelt werden muss.

Die wichtigsten Bausteine

In einer typischen OIDC-Architektur arbeiten mehrere Komponenten zusammen:

• der Identity Provider übernimmt die Anmeldung und stellt Tokens aus,
• der Client ist die Anwendung, die einen Nutzer authentifizieren möchte,
• der Resource Server stellt geschützte APIs oder Ressourcen bereit,
• Scopes legen fest, welche Informationen oder Berechtigungen angefordert werden,
• Claims enthalten die tatsächlich ausgestellten Informationen.

Ein Identity Provider kann damit zur zentralen Instanz für mehrere Anwendungen werden. Die einzelnen Anwendungen müssen nicht selbst Passwörter prüfen, sondern können sich auf einen standardisierten Authentifizierungsprozess verlassen.

ID Token, Access Token und Refresh Token

Ein wichtiger Bestandteil von OpenID Connect sind Tokens. Dabei erfüllen unterschiedliche Token-Arten unterschiedliche Aufgaben.

Der ID Token enthält Informationen über die Identität des angemeldeten Nutzers und ist für die Client-Anwendung bestimmt. Dazu können beispielsweise eine eindeutige Benutzer-ID oder freigegebene Profildaten gehören.

Der Access Token wird dagegen verwendet, um auf geschützte APIs zuzugreifen. Er enthält Informationen darüber, für welche Ressourcen und Berechtigungen der Zugriff erlaubt ist.

Ein Refresh Token kann verwendet werden, um nach Ablauf eines kurzlebigen Access Tokens einen neuen anzufordern, ohne dass sich der Nutzer erneut anmelden muss.

Häufig werden solche Tokens als JSON Web Tokens, kurz JWT, umgesetzt. Wichtig dabei: Ein JWT ist nicht automatisch verschlüsselt. Seine Inhalte können grundsätzlich ausgelesen werden. Vertrauliche Geheimnisse oder Informationen, die der Nutzer selbst nicht sehen darf, gehören deshalb nicht in den Token.

Authorization Code Flow und PKCE

Für moderne Web- und Mobile-Anwendungen spielt der Authorization Code Flow eine zentrale Rolle.

Dabei erhält die Anwendung nach erfolgreicher Anmeldung zunächst noch keinen fertigen Access Token. Stattdessen wird ein kurzlebiger Authorization Code ausgestellt. Erst in einem weiteren Schritt wird dieser Code gegen die benötigten Tokens eingetauscht.

Gerade bei Single Page Applications und nativen Apps entsteht jedoch ein besonderes Problem: Ein dauerhaft hinterlegtes Client Secret kann dort nicht sicher geschützt werden. JavaScript-Code lässt sich einsehen und auch mobile Anwendungen können analysiert werden.

Hier kommt PKCE – Proof Key for Code Exchange – ins Spiel. Die Anwendung erzeugt für jeden Anmeldevorgang einen zufälligen Code Verifier und leitet daraus eine Code Challenge ab. Die Challenge wird beim Start des Login-Prozesses mitgeschickt. Beim späteren Token-Austausch muss die Anwendung den ursprünglichen Verifier vorweisen.

Selbst wenn ein Angreifer den Authorization Code abfangen würde, könnte er ihn ohne den passenden Verifier nicht gegen Tokens eintauschen.

Zusätzlich schützen zufällige Werte wie state und nonce den Ablauf gegen Manipulationen und die Wiederverwendung alter Authentifizierungsinformationen.

Tokens sicher speichern

Die Wahl des richtigen Authentifizierungsprotokolls allein reicht nicht aus. Entscheidend ist auch, wie die ausgestellten Tokens behandelt werden.

Insbesondere länger gültige Refresh Tokens sollten nicht ungeschützt im Local Storage oder Session Storage eines Browsers abgelegt werden. Diese Speicherbereiche können über JavaScript ausgelesen werden und stellen bei Cross-Site-Scripting-Angriffen ein erhöhtes Risiko dar.

Kurzlebige Access Tokens können beispielsweise nur im Arbeitsspeicher der Anwendung gehalten werden. Für höhere Sicherheitsanforderungen bieten sich Architekturen an, bei denen besonders sensible Tokens gar nicht erst im Browser verfügbar sind.

Beim sogenannten Backend-for-Frontend-Pattern übernimmt ein serverseitiger Dienst einen großen Teil des Authentifizierungskontexts. Eine weitere Möglichkeit besteht darin, nur den Refresh Token serverseitig beziehungsweise über einen geschützten HttpOnly-Cookie zu verwalten und dem Frontend lediglich kurzlebige Access Tokens bereitzustellen.

Welche Variante sinnvoll ist, hängt von der Architektur, den Sicherheitsanforderungen und der jeweiligen Anwendung ab.

Das Backend muss Tokens validieren

Ein Access Token darf nicht allein deshalb akzeptiert werden, weil er formal wie ein gültiger Token aussieht.

Das Backend prüft unter anderem:

• von welchem Identity Provider der Token stammt,
• für welche Anwendung oder API er bestimmt ist,
• ob seine Gültigkeitsdauer abgelaufen ist,
• ob er bereits gültig sein darf,
• ob seine kryptografische Signatur korrekt ist.

Die zur Signaturprüfung benötigten öffentlichen Schlüssel können über einen standardisierten JWKS-Endpunkt des Identity Providers bereitgestellt und anschließend zwischengespeichert werden.

Dadurch muss das Backend nicht bei jedem API-Aufruf erneut beim Identity Provider nachfragen. Ein gültig signierter und korrekt geprüfter Token kann eigenständig verifiziert werden.

Single Sign-On für mehrere Anwendungen

Ein weiterer großer Vorteil zentraler Identitätsdienste ist Single Sign-On.

Nach einer erfolgreichen Anmeldung besteht beim Identity Provider eine Session. Öffnet der Nutzer anschließend eine weitere angebundene Anwendung, kann diese Session erkannt werden. Eine erneute Eingabe von Benutzername und Passwort ist dann nicht notwendig.

Das ist besonders hilfreich, wenn mehrere Anwendungen innerhalb einer Organisation genutzt werden. Nutzer melden sich einmal an und können anschließend zwischen verschiedenen Systemen wechseln.

Damit entstehen allerdings auch neue Anforderungen an das Logout. Wird lediglich der lokale Token einer einzelnen Anwendung gelöscht, kann die zentrale Session beim Identity Provider weiterhin bestehen.

Für ein sauberes Logout sollte deshalb auch die zentrale Session beendet werden. Bei mehreren verbundenen Anwendungen können zusätzlich Front-Channel- oder Back-Channel-Mechanismen dafür sorgen, dass auch andere Anwendungen über die Abmeldung informiert werden.

Identity Provider als zentrale Integrationsschicht

Ein zentraler Identity Provider kann mehr leisten als nur Benutzername und Passwort zu prüfen.

Lösungen wie Keycloak unterstützen beispielsweise OpenID Connect, OAuth 2.0 und weitere Authentifizierungsstandards. Anwendungen werden als Clients registriert und können über Rollen, Scopes und individuell konfigurierbare Login-Flows gesteuert werden.

Darüber hinaus können externe Identity Provider angebunden werden. Die Anwendung selbst kommuniziert dann weiterhin nur mit dem zentralen Identity Provider. Dieser übernimmt im Hintergrund die Kommunikation mit den externen Anmeldediensten.

Dieses sogenannte Identity Brokering reduziert die Kopplung zwischen Anwendung und konkretem Login-Anbieter. Wird später ein weiterer Provider ergänzt oder ausgetauscht, muss die eigentliche Anwendung dadurch nicht zwingend angepasst werden.

Auch zusätzliche Benutzerinformationen lassen sich über Claims und Mapper kontrolliert in Tokens aufnehmen. Dabei sollte immer nur jene Information bereitgestellt werden, die für den jeweiligen Anwendungsfall tatsächlich benötigt wird.

Fazit

OpenID Connect bietet eine standardisierte Grundlage für moderne Authentifizierungsarchitekturen. Anwendungen können die Anmeldung an einen zentralen Identity Provider auslagern, während Access Tokens den Zugriff auf geschützte APIs steuern.

Der eigentliche Sicherheitsgewinn entsteht jedoch erst durch eine saubere Gesamtarchitektur: Authorization Code Flow mit PKCE, sichere Token-Speicherung, kurze Gültigkeitszeiten, konsequente Token-Validierung und ein durchdachtes Session- und Logout-Konzept gehören zusammen.

Auch Single Sign-On und Identity Brokering zeigen, dass moderne Authentifizierung weit über eine einzelne Login-Maske hinausgeht. Richtig umgesetzt entsteht eine zentrale, flexible und erweiterbare Identitätsschicht für unterschiedliche Anwendungen und Plattformen.

Wir bei Aschauer IT betrachten Authentifizierung deshalb als Bestandteil der gesamten Lösungsarchitektur. Gemeinsam berücksichtigen wir Sicherheitsanforderungen, Benutzerfreundlichkeit, Schnittstellen und langfristige Wartbarkeit, um Zugriffsprozesse sicher und gleichzeitig praktikabel zu gestalten.

Wenn ihr Fragen habt oder mehr über konkrete Einsatzmöglichkeiten erfahren möchtet, nutzt bitte den unten angelegten Kontaktbereich. Wir unterstützen euch gerne bei eurem Vorhaben.