Einblicke
Die Abmeldekette
Eine Person meldet sich einmal an. Im Hintergrund entstehen aber mehrere Sitzungen. Beim Abmelden kommt es darauf an, welche davon beendet werden und wie die Nachricht alle beteiligten Systeme erreicht.
Eine Anmeldung, drei Schlüssel
Sie ergänzen Ihren Dienst um „Mit Google anmelden“. Für den Nutzer ist das ein einziger Klick.
Im Hintergrund erstellt und verwaltet jedes beteiligte System eine eigene Sitzung. Google hat eine, Authrim eine und Ihre Anwendung eine. Insgesamt drei.
Eine verbleibende Sitzung kann die weitere Nutzung oder eine erneute Anmeldung ohne Passworteingabe ermöglichen.
Abmelden bedeutet mehr als „Sie wurden abgemeldet“ anzuzeigen.
Es bedeutet, den Geltungsbereich festzulegen und die Sitzungen darin zu beenden.
Token-Widerruf ist ein eigener Vorgang
Die „Schlüssel“ stehen hier für Sitzungen. Access- und Refresh-Tokens funktionieren anders. Das Beenden einer Sitzung macht bereits ausgestellte Tokens nicht unbedingt ungültig. Dafür ist ein gesonderter Widerruf erforderlich.
In OIDC sind Sitzungsabmeldung, Token-Widerruf und die Deaktivierung eines vorgelagerten Kontos drei verschiedene Vorgänge. Dieser Artikel behandelt Sitzungen. Wann ein Token nicht mehr akzeptiert wird, beschreibt die Dokumentation zu Token-Introspektion und -Widerruf.
Authrim steht dazwischen
Der vorgelagerte Anbieter stellt die Anmeldung bereit, Ihre Anwendung fordert sie an. Authrims Rolle hängt davon ab, mit welcher Seite es kommuniziert.
Die Abmeldung bleibt oft unterwegs stecken
Die Anmeldung führt durch die Kette. Die Abmeldung muss dagegen ausdrücklich weitergereicht werden.
Das Beenden der vorgelagerten Sitzung entfernt nicht automatisch die Sitzungen in Authrim und Ihrer Anwendung. Die Nachricht muss weitergegeben werden, und jeder Empfänger muss die passende Sitzung beenden. Die folgende Grafik zeigt die Kette bei passenden Benachrichtigungsverfahren und Einstellungen.
Wie sich das im Alltag auswirkt
| Situation | Folge einer unterbrochenen Kette |
|---|---|
| Austritt aus dem Unternehmen | Der Zugang wird entzogen. Auf dem Laptop bleibt die Anwendung jedoch geöffnet, und interne Daten sind noch bis zum nächsten Morgen sichtbar. |
| Gemeinsam genutzte Geräte | Im Geschäft, Krankenhaus oder Callcenter meldet sich jemand ab. Ein zweiter Tab zeigt trotzdem noch dessen Dashboard. |
| Verlorenes Gerät | „Überall abmelden“ wurde gewählt. Tatsächlich endete nur die gerade verwendete Sitzung. |
| Reaktion auf einen Vorfall | Das kompromittierte Konto wird gesperrt. Die Sitzung des Angreifers bleibt bis zum Ablauf gültig. |
| Audit | „Zeigen Sie, dass die Abmeldung alle Systeme erreicht.“ Ein Nachweis fehlt. |
Der Abmeldeknopf fehlt in keinem dieser Fälle. Die Seite ändert sich auch. Aber die Wirkung reicht weniger weit als angenommen. Gerade deshalb fällt das Problem so schwer auf.
Der Weg über den Browser wird unzuverlässig
Es gibt zwei Wege, die Anwendungen zu benachrichtigen. Einer davon stößt zunehmend an Grenzen.
Authrims Zertifizierung umfasst den Empfang über den Back-Channel. Empfang und Weiterleitung einer Nachricht müssen jeweils geprüft werden.
Empfänger und Absender getrennt prüfen
Gegenüber dem vorgelagerten Anbieter ist Authrim eine Relying Party (RP), gegenüber den Anwendungen ein OpenID Provider (OP). Um die Abmeldung weiterzugeben, muss es in beiden Rollen die Spezifikationen erfüllen.
- Als RP: Die vorgelagerte Abmeldenachricht prüfen und die passende Authrim-Sitzung beenden.
- Als OP: Abmeldenachrichten senden, damit angebundene Anwendungen die passenden Sitzungen beenden können.
Die Zertifizierungen für OP- und RP-Logout-Profile liefern Nachweise für diese beiden Rollen. Authrim hat auf beiden Seiten zertifizierte Logout-Profile im Selbstzertifizierungsverfahren der OpenID Foundation, das deren offizielle Konformitätstests verwendet.
Eine Zertifizierung bedeutet, dass die eingereichte Implementierungsversion die Konformitätstests der eingereichten Profile bestanden hat. Sie garantiert nicht, dass jede Sitzung in den Anwendungen und im Netzwerk eines Kunden sofort endet.
Der vorgelagerte Anbieter und jede Anwendung müssen die nötigen Verfahren unterstützen. Benachrichtigungsendpunkte und Sitzungszuordnung müssen eingerichtet sein. Die Deaktivierung eines vorgelagerten Kontos löst nicht zwingend eine Abmeldenachricht aus. Auch Zustellfehler, Wiederholungen und die Sichtbarkeit von Fehlern sind in der konkreten Umgebung zu prüfen.
Zertifizierte Versionen und Profile stehen im Verzeichnis Certified OpenID Relying Parties & Logout Profiles der OpenID Foundation. Den Umfang erläutert die Beschreibung des Zertifizierungsverfahrens.
Wo bleibt nach dem Abmelden noch eine Sitzung aktiv?
Diese Frage zählt, wenn ein gemeinsam genutztes Gerät weitergegeben oder der Zugang ehemaliger Mitarbeitender beendet wird. Authrim empfängt und sendet Nachrichten, um die Sitzungsbeendigung vom vorgelagerten Anbieter bis zu den Anwendungen zu verbinden. Die Zertifizierung belegt Eigenschaften der Implementierung. Ob die Abmeldung im gewünschten Umfang ankommt, zeigen Tests der tatsächlich verbundenen Systeme.