Implementierung von OIDC-Logout und Sitzungsverwaltung: Ein umfassender Leitfaden

Was ist OIDC-Sitzungsmanagement?#

OpenID Connect (OIDC) ist eine einfache Identitätsschicht, die auf dem OAuth 2.0-Protokoll basiert. Sie ermöglicht es Clients, die Identität des Endbenutzers basierend auf der vom Autorisierungsserver durchgeführten Authentifizierung zu überprüfen sowie grundlegende Profilinformationen über den Endbenutzer in einer interoperablen und REST-ähnlichen 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ätsprüfung in Webanwendungen, mobilen Apps und APIs genutzt.

Das Verständnis des Authentifizierungsstatus und der Sitzungsverwaltung in OIDC ist entscheidend. Dieser Artikel erklärt, wie OIDC-Sitzungen und der Benutzerauthentifizierungsstatus im Kontext der Interaktionen zwischen dem Identitätsanbieter (IdP) und der anfragenden Partei (RP) oder Dienstanbieter (SP) verwaltet werden.

Dieser Artikel enthält mehrere wichtige Begriffe.

• Identitätsanbieter (IdP): Der Dienst, der Benutzeridentitäten speichert und authentifiziert.
• Dienstanbieter (SP) oder Anfragende Partei (RP): Eine Webanwendung oder ein Dienst, der Dienste für Benutzer bereitstellt und auf den IdP für die Benutzerauthentifizierung vertraut.
• Anmeldesitzung oder Authentifizierungssitzung: Die Sitzung, die eingerichtet wird, wenn sich ein Benutzer beim IdP anmeldet.
• Grant: Die zentralisierte Benutzerautorisierungs- und Authentifizierungsinformation, die vom IdP generiert und verwaltet wird.
• Single Sign-On (SSO): Ein Sitzungs- und Benutzerauthentifizierungsdienst, der es einem Benutzer erlaubt, ein Login-Set (z. B. Name und Passwort) zu nutzen, um auf mehrere Anwendungen zuzugreifen.

Wie funktioniert der OIDC-Authentifizierungsablauf?#

Um das OIDC-Sitzungs- und Benutzerauthentifizierungsstatusmanagement besser zu verstehen, werfen wir einen kurzen Blick auf den OIDC-Authentifizierungsablauf für eine Webanwendung:

1. Der Benutzer greift auf die Webanwendung (RP) zu.
2. Der RP leitet den Benutzer zu dem OIDC-Anbieter (IdP) zur Authentifizierung weiter.
3. Der OIDC-Anbieter überprüft den Anmeldesitzungsstatus 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-Anmeldesitzungsmanagement?#

Eine Anmeldesitzung wird eingerichtet, wenn sich ein Benutzer beim IdP anmeldet. Diese Sitzung wird verwendet, um den Authentifizierungsstatus des Benutzers beim IdP zu verfolgen. Die Sitzung enthält typischerweise Informationen wie die Identität des Benutzers, die Authentifizierungszeit und die Ablaufzeit der Sitzung. Sie wird erstellt, wenn der Benutzer sich zuerst anmeldet, und bleibt bestehen, bis der Benutzer sich abmeldet oder die Sitzung abläuft.

Ein Sitzungscookie wird sicher im Browser des Benutzers gesetzt, um den Sitzungsstatus aufrechtzuerhalten. Das Sitzungscookie wird verwendet, um die Benutzersitzung zu identifizieren und den Benutzer für nachfolgende Authentifizierungsanforderungen zu authentifizieren. Dieses Cookie wird in der Regel mit den Flags HttpOnly und Secure gesetzt, um den Zugriff von der Client-Seite zu verhindern und eine sichere Kommunikation zu gewährleisten.

Eine Sitzung für einen einzelnen RP#

Für jeden RP, auf den der Benutzer von verschiedenen Geräten oder Browsern zugreift, wird eine separate Benutzeranmeldesitzung eingerichtet. Dies bedeutet, dass der Authentifizierungsstatus des Benutzers für jeden RP separat aufrechterhalten wird. Wenn sich der Benutzer von einem RP abmeldet, bleibt er bei anderen RPs weiterhin 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) stammen. Dieser Mechanismus ermöglicht SSO-Funktionen, 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 Clientanwendung (RP) auf die vom IdP ausgegebenen Tokens, um die Identität des Benutzers und dessen Authentifizierungs- oder Autorisierungsstatus zu überprüfen. Die "Anmeldesitzung" auf der Client-Seite wird durch die vom IdP ausgestellten Tokens aufrechterhalten.

• ID-Token: Ein kurzlebiger Token, der Benutzerinformationen enthält und verwendet wird, um die Identität des authentifizierten Benutzers zu überprüfen.
• Zugriffstoken: Ein Token, das den Zugriff auf geschützte Ressourcen im Namen des Benutzers gewährt. Die Lebensdauer des Zugriffstokens kann kurzlebig oder langlebig sein, je nach Konfiguration. Clientanwendungen können sich auf die Gültigkeit des Zugriffstokens verlassen, um den Authentifizierungsstatus des Benutzers zu bestimmen. Wenn das Zugriffstoken abgelaufen oder gelöscht ist, kann der Benutzer als "abgemeldet" oder "nicht authentifiziert" betrachtet werden und muss sich erneut authentifizieren.
• Aktualisierungstoken: Wenn der offline_access-Bereich angefordert und gewährt wird, kann die Clientanwendung ein Aktualisierungstoken erhalten. Es bietet eine Möglichkeit, den Authentifizierungsstatus des Benutzers zu verlängern, ohne dass der Benutzer sich erneut authentifizieren muss. Die Clientanwendung kann das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, wenn das aktuelle Zugriffstoken abläuft. Solange das Aktualisierungstoken gültig ist, kann der Authentifizierungsstatus des Benutzers ohne Benutzerinteraktion aufrechterhalten werden.

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

OIDC-Abmeldeverfahren#

Der Abmeldeprozess in OIDC ist aufgrund der Beteiligung sowohl von zentralisierten, durch den IdP verwalteten Anmeldesitzungen als auch von verteilten Client-seitigen Tokens ein mehrschichtiges Konzept.

Tokens und lokale Sitzung auf der Clientseite löschen#

Um den Authentifizierungsstatus eines Benutzers auf der Client-Seite abzumelden oder zu widerrufen, ist relativ einfach. Die Clientanwendung kann gespeicherte Tokens (ID-Token, Zugriffstoken und Aktualisierungstoken) aus dem Browser oder dem Speicher des Benutzers entfernen. Diese Aktion hebt effektiv den Authentifizierungsstatus des Benutzers auf der Client-Seite auf.

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 jeglicher Sitzungsdaten (wie von der Identity Provider oder IdP ausgestellte Tokens), um sicherzustellen, dass der Benutzer vollständig abgemeldet ist.

Zentrale Anmeldesitzung beim IdP löschen#

Der IdP verwaltet eine zentrale Anmeldesitzung für jeden Benutzer. Solange diese Sitzung aktiv ist, kann der Benutzer automatisch erneut authentifiziert werden, selbst wenn die Client-seitigen Tokens gelöscht wurden, was es ermöglicht, neue Tokens an die Clientanwendung auszustellen, ohne dass eine weitere Interaktion mit dem IdP erforderlich ist.

Um einen Benutzer vollständig vom IdP abzumelden, kann die Clientanwendung (RP) eine Abmeldeanforderung an den IdP initiieren. Die Anwendung (RP) sollte den Benutzer zur End-Sitzung-Endpunkt des IdP umleiten, um die Anmeldesitzung zu beenden und Sitzungscookies zu löschen. Dies stellt sicher, dass eine vollständige Abmeldung über alle Anwendungen (RPs), die eine gleiche zentrale Sitzung teilen, erfolgt. Sobald die Anmeldesitzung beendet ist, wird der IdP den Benutzer auffordern, sich erneut zu authentifizieren, wann immer er eine Token-Anforderung von einem der verbundenen RPs erhält, die die gleiche Sitzung teilen.

OIDC-Back-Channel-Logout#

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

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

Wenn die RPs die Back-Channel-Logout-Benachrichtigung erhalten, können sie die notwendigen Schritte unternehmen, um die Sitzung und die Tokens des Benutzers zu löschen, sodass der Benutzer vollständig von allen Anwendungen abgemeldet ist.