OIDC-Session-Management

Was ist OIDC-Session-Management#

OpenID Connect (OIDC) ist eine einfache Identitätsschicht, die auf dem OAuth 2.0-Protokoll aufbaut. Es ermöglicht Clients, die Identität des Endbenutzers basierend auf der vom Autorisierungsserver durchgeführten Authentifizierung zu verifizieren und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise zu erhalten.

OIDC ist darauf ausgelegt, einfach zu verwenden und zu implementieren zu sein, mit einem Fokus auf Einfachheit und Flexibilität. Es wird häufig für Single Sign-On (SSO) und Identitätsverifikation in Webanwendungen, mobilen Apps und APIs verwendet.

Das Verstehen des Authentifizierungsstatus und der Sitzungsverwaltung in OIDC ist entscheidend. Dieser Artikel erklärt, wie OIDC-Sitzungen und der Authentifizierungsstatus von Benutzern im Kontext der Interaktion zwischen dem Identity Provider (IdP) und der relying party (RP) oder dem Service Provider (SP) verwaltet werden.

Dieser Artikel enthält mehrere Schlüsselbegriffe.

• Identity Provider (IdP): Der Dienst, der Benutzeridentitäten speichert und authentifiziert.
• Service Provider (SP) oder Reliant Party (RP): Eine Webanwendung oder ein Dienst, der Benutzern Dienste anbietet und auf den IdP für die Benutzerauthentifizierung angewiesen ist.
• Anmelde-Session oder Authentifizierungs-Session: Die Sitzung, die entsteht, wenn sich ein Benutzer beim IdP anmeldet.
• Grant: Die zentrale Benutzer-Authentifizierungs- und Autorisierungsinformation, die vom IdP generiert und verwaltet wird.
• Single Sign-On (SSO): Ein Sitzungs- und Benutzer-Authentifizierungsdienst, der es einem Benutzer erlaubt, ein Set von Anmeldeinformationen (z.B. Name und Passwort) zu verwenden, um auf mehrere Anwendungen zuzugreifen.

Wie funktioniert der OIDC-Authentifizierungsprozess#

Um die Verwaltung von OIDC-Session und Benutzerauthentifizierungsstatus besser zu verstehen, lassen Sie uns den OIDC-Authentifizierungsprozess für eine Webanwendung kurz überprüfen:

1. Der Benutzer greift auf die Webanwendung (RP) zu.
2. Der RP leitet den Benutzer zur OIDC-Anbieter (IdP) zur Authentifizierung um.
3. Der OIDC-Anbieter überprüft den Status der Anmeldesitzung des Benutzers. Wenn keine Sitzung existiert oder die Sitzung abgelaufen ist, wird der Benutzer aufgefordert, sich anzumelden.
4. Der Benutzer interagiert mit der Anmeldeseite, um sich zu authentifizieren.
5. Die Anmeldeseite übermittelt das Interaktionsergebnis an den OIDC-Anbieter.
6. Der OIDC-Anbieter erstellt eine neue Anmeldesitzung und einen Authentifizierungs-Grant für den Benutzer.
7. Der OIDC-Anbieter leitet den Benutzer mit einem Authentifizierungscode (Authorization Code Flow) zurück zur RP.
8. Der RP erhält den Authentifizierungscode und tauscht ihn gegen Tokens aus, um auf Benutzerinformationen zuzugreifen.

Was ist RP-Sitzungsmanagement#

Eine Anmeldesitzung wird erstellt, wenn sich ein Benutzer beim IdP anmeldet. Diese Sitzung wird verwendet, um den Authentifizierungsstatus des Benutzers beim IdP nachzuverfolgen. Die Sitzung umfasst typischerweise Informationen wie die Identität des Benutzers, die Authentifizierungszeit und die Ablaufzeit der Sitzung. Sie wird erstellt, wenn sich der Benutzer zum ersten Mal anmeldet, und wird aufrechterhalten, bis der Benutzer sich abmeldet oder die Sitzung abläuft.

Ein Sitzungscookie wird sicher im Browser des Benutzers gesetzt, um den Sitzungszustand zu erhalten. Das Sitzungscookie wird verwendet, um die Sitzung des Benutzers zu identifizieren und den Benutzer für nachfolgende Authentifizierungsanfragen zu authentifizieren. Dieses Cookie wird typischerweise mit den Flags HttpOnly und Secure gesetzt, um clientseitigen Zugriff zu verhindern und eine sichere Kommunikation zu gewährleisten.

Eine Sitzung für eine einzelne RP#

Für jede RP, auf die der Benutzer von verschiedenen Geräten oder Browsern zugreift, wird eine separate Benutzersitzung eingerichtet. Das bedeutet, dass der Authentifizierungsstatus des Benutzers für jede RP separat aufrechterhalten wird. Wenn sich der Benutzer von einer RP abmeldet, bleibt der Benutzer bei anderen RPs authentifiziert, bis die Sitzung abläuft oder der Benutzer sich von allen RPs abmeldet.

Zentralisierte Sitzung für mehrere RPs#

Diese zentralisierte Sitzungsverwaltung ermöglicht es dem IdP auch, einen konsistenten Authentifizierungsstatus über mehrere RPs aufrechtzuerhalten, solange die Sitzung des Benutzers aktiv ist und die Authentifizierungsanfragen vom selben Benutzeragenten (Gerät/Browser) kommen. Dieser Mechanismus ermöglicht SSO-Fähigkeiten, bei denen der Benutzer auf mehrere RPs zugreifen kann, ohne sich erneut anmelden zu müssen.

Client-seitiger Authentifizierungsstatus#

In OIDC verlässt sich die Client-Anwendung (RP) auf die vom IdP ausgestellten Tokens, um die Identität und den Authentifizierungs- oder Autorisierungsstatus des Benutzers zu überprüfen. Die "Anmeldesitzung" auf der Client-Seite wird durch die vom IdP ausgegebenen Tokens aufrechterhalten.

• ID-Token: Ein kurzlebiges Token, das Benutzerinformationen enthält und zur Überprüfung der Identität des authentifizierten Benutzers verwendet wird.
• Access-Token: Ein Token, das den Zugriff auf geschützte Ressourcen im Namen des Benutzers gewährt. Die Lebensdauer des Access-Tokens kann kurzlebig oder langlebig sein, abhängig von der Konfiguration. Client-Anwendungen können sich auf die Gültigkeit des Access-Tokens verlassen, um den Authentifizierungsstatus des Benutzers zu bestimmen. Wenn das Access-Token abläuft oder gelöscht wird, kann der Benutzer als "abgemeldet" oder "nicht authentifiziert" betrachtet werden und muss sich erneut authentifizieren.
• Refresh-Token: Wenn der offline_access-Scope angefordert und genehmigt wurde, kann die Client-Anwendung ein Refresh-Token erhalten. Es bietet eine Möglichkeit, den Authentifizierungsstatus des Benutzers zu verlängern, ohne dass der Benutzer sich erneut authentifizieren muss. Die Client-Anwendung kann das Refresh-Token verwenden, um ein neues Access-Token zu erhalten, wenn das aktuelle Access-Token abläuft. Solange das Refresh-Token gültig ist, kann der Authentifizierungsstatus des Benutzers ohne Benutzerinteraktion aufrechterhalten werden.

Die Kombination dieser Tokens ermöglicht es der Client-Anwendung, den Authentifizierungsstatus des Benutzers aufrechtzuerhalten und im Namen des Benutzers auf geschützte Ressourcen zuzugreifen. Die Client-Anwendung muss diese Tokens sicher speichern und ihren Lebenszyklus verwalten. (Zum Beispiel können bei SPA-Anwendungen die Tokens im lokalen Speicher oder Sitzungsspeicher des Browsers gespeichert werden. Bei Webanwendungen können die Tokens in den serverseitigen Sitzungsdaten oder Cookies gespeichert werden.)

OIDC-Abmeldemechanismen#

Der Abmeldeprozess in OIDC ist ein vielschichtiges Konzept aufgrund der Beteiligung von sowohl zentralisierten, vom IdP verwalteten Anmeldesitzungen als auch verteilten clientseitigen Tokens.

Tokens und lokale Sitzung auf der Client-Seite löschen#

Das Abmelden oder Widerrufen des Authentifizierungsstatus eines Benutzers auf der Client-Seite ist relativ einfach. Die Client-Anwendung kann gespeicherte Tokens (ID-Token, Access-Token und Refresh-Token) aus dem Browser oder Speicher des Benutzers entfernen. Diese Aktion macht den Authentifizierungsstatus des Benutzers auf der Client-Seite effektiv ungültig.

Für Webanwendungen, die ihre eigenen Benutzer-Anmeldesitzungen verwalten, können zusätzliche Schritte erforderlich sein. Dazu gehört das Löschen des Sitzungscookies und aller Sitzungsdaten (z. B. Tokens, die vom Identity Provider, oder IdP, ausgegeben wurden), um sicherzustellen, dass der Benutzer vollständig abgemeldet ist.

Zentralisierte Anmeldesitzung beim IdP löschen#

Der IdP verwaltet eine zentralisierte Anmeldesitzung für jeden Benutzer. Solange diese Sitzung aktiv ist, kann der Benutzer automatisch erneut authentifiziert werden, selbst wenn clientseitige Tokens gelöscht wurden, sodass neue Tokens an die Client-Anwendung ausgegeben werden können, ohne weitere Interaktion mit dem IdP erforderlich zu machen.

Um einen Benutzer vollständig vom IdP abzumelden, kann die Client-Anwendung (RP) eine Abmeldeanforderung an den IdP initiieren. Die Anwendung (RP) sollte den Benutzer zum End-Session-Endpunkt des IdP umleiten, um die Anmeldesitzung zu beenden und Sitzungscookies zu löschen. Dies gewährleistet eine vollständige Abmeldung über alle Anwendungen (RPs) hinweg, die die gleiche zentralisierte Sitzung teilen. Sobald die Anmeldesitzung beendet ist, wird der IdP, wenn er eine Tokenanfrage von einem der verknüpften RPs erhält, den Benutzer auffordern, sich erneut zu authentifizieren.

OIDC-Back-Channel-Logout#

In manchen Fällen, wenn sich ein Benutzer von einer Anwendung (RP) abmeldet, möchten sie möglicherweise auch automatisch von allen anderen Anwendungen (RPs) abgemeldet werden, ohne dass zusätzliche Benutzerinteraktion erforderlich ist. Dies kann durch den Back-Channel-Logout-Mechanismus erreicht werden.

Wenn der IdP eine Abmeldeanforderung von einer RP erhält, löscht er nicht nur die Anmeldesitzung, sondern sendet auch eine Back-Channel-Logout-Benachrichtigung an alle RPs, die dieselbe Sitzung verwenden und einen registrierten Back-Channel-Logout-Endpunkt haben.

Wenn die RPs die Back-Channel-Logout-Benachrichtigung erhalten, können sie die erforderlichen Aktionen durchführen, um die Sitzung und Tokens des Benutzers zu löschen und sicherstellen, dass der Benutzer vollständig von allen Anwendungen abgemeldet wird.