Ein OIDC-Back-Channel-Logout beendet die Sitzungen eines Benutzers in einer App. Er widerruft nicht den Tenant des Kunden

Ein OIDC-Back-Channel-Logout beendet die Sitzungen eines Benutzers in einer App. Er widerruft nicht den Tenant des Kunden

Die Frage, die ein MSP nach einem Incident-Call vom Kunden hört, lautet: „Unser IdP hat einen Back-Channel-Logout gesendet, also ist der gesamte Tenant des Kunden abgeschnitten, oder?“ Die kurze Antwort lautet nein. Nach OpenID Connect Back-Channel Logout 1.0 sendet der Identity Provider ein signiertes Logout Token per POST an eine Relying Party, und dieses Token benennt einen einzelnen Endbenutzer (Issuer plus Subject) und/oder eine einzelne Sitzung. Fehlt die Sitzungskennung, beendet die Relying Party alle Sitzungen dieses Benutzers bei genau dieser Relying Party – und nichts darüber hinaus. Es gibt keinen Tenant-Claim und keine Bedeutung im Sinne von „alle widerrufen“.

Diese FAQ beantwortet sechs Fragen, die MSPs stellen, wenn ein Logout-Signal mit Off-Boarding verwechselt wird. Was beweist ein 200 OK vom Logout-Endpunkt, und was beweist es nicht? Warum liegen Machine-to-Machine-Integrationen vollständig außerhalb des Logout-Pfads? Warum beendet das Ende der IdP-Sitzung nicht automatisch die App-Sitzungen, wie NIST SP 800-63C-4 (26. August 2025) festhält? Wo ist ein Widerrufssignal mit Tenant- oder Policy-Bezug angesiedelt – bei CAEP über das Shared Signals Framework –, und warum ersetzt selbst dieses nicht die Autorisierungsprüfung bei jeder Anfrage? Und warum ist Logout keine Deprovisionierung?

Die Regel dieses Beitrags ist einfach: Das Off-Boarding eines Tenants ist eine Administrations- und Autorisierungsmaßnahme, niemals ein Nebeneffekt eines Logouts. Quellen sind die Texte von OpenID, IETF, NIST und OWASP, geprüft am 5. Oktober 2026. Es gibt keine Token-Konstruktion und keine Behauptung, dass ein Altovar-Produkt diese Logout- oder Shared-Signals-Ereignisse sendet oder empfängt.

Wird der gesamte Tenant des Kunden widerrufen, wenn der IdP einen Back-Channel-Logout sendet? In den Worten des Kunden: „Sie haben sich abgemeldet, also sind alle bei diesem Kunden draußen.“ Die Antwort ist nein. Eine Back-Channel-Logout-Anfrage ist ein POST vom Identity Provider an die Relying Party mit einem signierten Logout Token, wie es OIDC Back-Channel Logout 1.0, Abschnitt 2.4, definiert. Das Token identifiziert einen Endbenutzer über Issuer und Subject und/oder eine Sitzung über die Sitzungs-ID. Das ist der Radius, den der Standard dem Signal gibt.

Fehlt die Sitzungs-ID, beendet die Relying Party alle Sitzungen dieses Benutzers bei dieser Relying Party. Weiter geht der Standard nicht. Es bleibt ein Benutzer und eine App. Wer jede Browser-Sitzung beendet, die Alice im Ticketportal hat, beendet damit weder Bobs Sitzungen im selben Portal noch Alices Sitzungen in einem anderen Portal, das nie ein Logout Token erhalten hat.

Das Logout Token enthält keinen Tenant-Claim und bedeutet nicht „alle widerrufen“. Eine Relying Party, die einen Logout als Tenant-Widerruf behandelt, erfindet ein Verhalten, das die Spezifikation nicht definiert. Ein Tenant-Widerruf – als Reihe getrennter Administrationsschritte, nicht als Produktanleitung – bedeutet: den Tenant-Datensatz deaktivieren, seine Grants und Client-Registrierungen widerrufen, die von ihm gehaltenen Zugangsdaten rotieren und dafür sorgen, dass der Policy Decision Point seine Anfragen ablehnt. Jeder Schritt hat einen Verantwortlichen und einen Audit-Trail. Keiner davon ist ein Logout.

Eine kurze Anmerkung zu Signaturen, bewusst auf hoher Ebene: Die Spezifikation verlangt, dass das Logout Token signiert und kurzlebig ist, gerade damit eine Relying Party nicht auf einen gefälschten oder wiedereingespielten Logout reagiert. Dieser Artikel beschreibt nicht, wie ein Token erstellt oder geprüft wird. Für den MSP zählt der Radius: ein Benutzer, eine App, nicht der Tenant des Kunden.

Der Logout-Endpunkt hat 200 OK zurückgegeben. Sind damit alle Tokens des Benutzers ungültig? Nicht unbedingt. Ein 200 OK bedeutet, dass die Relying Party den Zustand der Sitzungen bereinigt hat, die ihr genannt wurden. Es ist eine Quittung dieser Relying Party, kein Beleg dafür, dass jedes Token überall verschwunden ist.

Für Refresh Tokens gilt nach Back-Channel Logout, Abschnitt 2.7, eine engere Regel. Refresh Tokens, die an die abgemeldete Sitzung gebunden sind und ohne offline_access ausgestellt wurden, SOLLTEN widerrufen werden; Offline-Access-Refresh-Tokens SOLLTEN es in der Regel NICHT. Das ist eine allgemeine Eigenschaft des Standards. Dieser Artikel verknüpft sie nicht mit der Konfiguration eines bestimmten Anbieters und nennt keine Idle- oder Laufzeitwerte.

Bei Access Tokens sieht es anders aus. Ein selbsttragendes (JWT-)Access-Token bleibt bis zu seinem Ablauf gültig, es sei denn, der Resource Server prüft es live per Introspection (RFC 7662) oder das Token wird am Authorization Server widerrufen (RFC 7009). RFC 7009, Abschnitt 3, weist selbst darauf hin, dass der sofortige Widerruf selbsttragender Access Tokens eine zusätzliche, nicht standardisierte Abstimmung zwischen Authorization Server und Resource Server oder kurze Token-Laufzeiten erfordert. Ein 200 OK beim Logout ist diese Abstimmung nicht.

Eine Leitplanke zur Introspection in einem Satz: active: true bedeutet, dass das Token ausgestellt und weder widerrufen noch abgelaufen ist. Es sagt nichts darüber aus, ob dieser Tenant oder diese Aktion erlaubt ist. Das ist eine eigene Frage, die dieser Beitrag nicht vertieft. Das OWASP Session Management Cheat Sheet ergänzt eine Zeile: Ein Logout muss die Sitzung serverseitig ungültig machen; das Löschen eines Browser-Cookies ist nicht dasselbe.

Schneidet ein Logout Machine-to-Machine-Integrationen ab? Nein. Back-Channel Logout beendet Sitzungen von Endbenutzern bei Relying Parties. Ein Maschinen-Client, der Tokens über den Client-Credentials-Grant bezieht, hat keine Benutzersitzung und keine Sitzungs-ID; ein Logout Token kann ihn also nicht adressieren. Das Signal kann nirgends ankommen.

Die Konsequenz für den MSP, in einfachen Worten: Der RMM-Connector, die Abrechnungssynchronisation und der API-Client des Backup-Agents arbeiten weiter, nachdem jeder Mensch beim Kunden abgemeldet wurde. Das ist korrektes Protokollverhalten, und genau deshalb ist „wir haben alle abgemeldet“ kein Off-Boarding-Nachweis. Die Menschen sind aus den Apps abgemeldet, die ein Logout Token erhalten haben. Die Integrationen sind keine Menschen und haben keines erhalten.

Das Off-Boarding einer Integration ist eine eigene Checkliste, formuliert als Ergebnisse statt als Klicks in einem Produkt: die Zugangsdaten des Clients deaktivieren oder rotieren, die bereits gehaltenen Tokens widerrufen und seine Tenant-Berechtigung am Entscheidungspunkt entfernen. Jeder dieser Schritte ist eine Administrations- und Autorisierungsmaßnahme mit einem Verantwortlichen. Keiner davon entsteht durch einen Logout-POST.

Beendet das Ende der IdP-Sitzung automatisch die App-Sitzungen? Nein. NIST SP 800-63C-4 (finale Revision 4, Seite vom 26. August 2025) stellt fest, dass das Beenden der Sitzung des Subscribers beim IdP Sitzungen, die dieser Subscriber bei nachgelagerten RPs haben könnte, „nicht notwendigerweise beendet“ (sinngemäß übersetzt). Beide Seiten können einander Sitzungsende-Ereignisse übermitteln, wenn das Föderationsprotokoll dies unterstützt, oder über Shared Signaling. „Können“ heißt nicht „werden“.

Back-Channel Logout ist ein solcher Mechanismus, und er arbeitet nach dem Best-Effort-Prinzip. Die Relying Party muss eine Back-Channel-Logout-URI registrieren, der Identity Provider muss sie erreichen können, und er wiederholt den Versand nur nach Fehlern, die er für behebbar hält (Back-Channel Logout, Abschnitt 2.5). Eine App, die sich nie registriert hat oder beim POST des IdP nicht erreichbar war, behält ihre Sitzung. Eine Firewall-Regel, eine veraltete URI oder eine fehlende Registrierung genügt, damit eine aktive Sitzung bestehen bleibt.

NIST SP 800-63B-4, Abschnitt 5, ergänzt eine Begriffsklärung: Sitzungen enden durch Timeout oder expliziten Logout, und das Föderationsverhalten wird an 63C verwiesen. „Der IdP hat ein Timeout ausgelöst“ und „jede App hat abgemeldet“ sind also zwei verschiedene Tatsachen. Ein MSP-Ticket, das beides vermischt, schließt die falsche Arbeit ab.

Das Abmelden eines Benutzers entfernt auch weder seine Tenant-Mitgliedschaft noch seine Rollen. NIST SP 800-63C-4 behandelt die Beendigung eines Subscriber-Kontos bei der Relying Party – das Entfernen von Kennungen, Authenticators und Attributen – als vom Sitzungsende getrennten Vorgang. Mitgliedschaft und Rollen sind Provisioning- und Autorisierungsdaten; sie zu ändern ist Deprovisionierung. Der Satz zum Merken: Sitzungsende ≠ Kontobeendigung ≠ Tenant-Off-Boarding.

Wo ist ein Widerruf mit Tenant-Bezug angesiedelt, wenn nicht in einem Logout Token? Das OpenID Shared Signals Framework 1.0 mit dem Continuous Access Evaluation Profile (CAEP 1.0, beide Final) definiert die Ereignisse session-revoked und token-claims-change. Deren Subject kann ein zusammengesetztes Subject mit einer Tenant-Komponente sein. Näher kommt ein Standard einer Widerrufsnachricht mit Tenant- oder Policy-Bezug nicht.

Es bleibt ein Signal: Der Empfänger entscheidet, was er damit tut. Ein Ereignis zu empfangen ist nicht dasselbe, wie den Zugriff widerrufen zu haben. Ein Produkt, das das Ereignis ignoriert, verzögert oder auf eine weiche Warnung abbildet, hat die Ablehnung nicht vollzogen. Das Ereignis ist ein Auslöser, nicht die Entscheidung.

Die Autorisierung im Produkt muss weiterhin standardmäßig ablehnen und bei jeder Anfrage Tenant-Status und Berechtigungen prüfen, wie es das OWASP Authorization Cheat Sheet beschreibt. Ein Logout- oder CAEP-Ereignis löst diese Prüfung aus, ersetzt sie aber nicht. Ein MSP, der „CAEP empfangen“ mit „Zugriff widerrufen“ gleichsetzt, überspringt den Entscheidungspunkt.

Dieser Artikel sagt nicht, welche Produkte CAEP senden oder empfangen. Insbesondere sagt er nicht, dass Auris das tut. Der Artikel beschreibt ausschließlich den Standard und behauptet nicht, dass ein Altovar-Produkt CAEP, SSF oder Back-Channel Logout unterstützt.

Dies ist keine FAQ zu PAR, PKCE oder Passkeys. Diese Themen betreffen, wie ein Login oder eine Autorisierungsanfrage beginnt. Dieser Beitrag behandelt, was ein Logout-Signal beendet. Eine Anfrage zu starten und eine Sitzung zu beenden sind verschiedene Aufgaben, und wer sie vermischt, erzeugt das falsche Ticket.

Es ist auch keine FAQ zu Group Claims oder SCIM. Provisioning- und Rollendaten kommen hier nur vor, um zu sagen, dass ein Logout sie nicht verändert. Mitgliedschaftseinträge und Rollenzuweisungen überstehen ein Logout Token, solange kein separater Administrationsschritt sie entfernt.

Ebenso wenig geht es um DPoP oder um Binding-Zeremonien für Authenticators. Sender-Constraint und Authenticator-Binding beantworten andere Fragen als der Radius eines Logouts.

Und es geht nicht um kurzlebige Tokens oder Token-TTLs. Diese Themen betreffen, wie lange ein Token lebt. Hier geht es um den Radius des Logout-Signals – Sitzung oder Benutzer gegenüber Tenant –, nicht um die Laufzeit. Ein kurzlebiges Access Token und ein Logout Token können beide in einem Stack vorkommen und Maschinen-Clients sowie andere Apps trotzdem unberührt lassen.

Dieser Artikel behauptet nicht, dass Auris Back-Channel Logout, CAEP oder SSF unterstützt, backchannel_logout_supported ausweist, eine Client-spezifische backchannel_logout_uri berücksichtigt oder Shared-Signals-Ereignisse sendet.

Der Satz zum Wiederholen: Ein Logout-Signal beendet Sitzungen; den Tenant eines Kunden zu widerrufen ist eine bewusste Administrations- und Autorisierungsentscheidung, die bei jeder Anfrage geprüft wird.