SSO-Sicherheit nach dem Login: Warum Tokens selbst geschützt werden müssen

SSO und MFA beantworten zunächst die Frage, wie ein Benutzer seine Identität nachweist. Nach der Anmeldung arbeiten Anwendungen und APIs jedoch mit anderen Artefakten weiter: Tokens, Assertions oder Sitzungsnachweisen, die Identität und Zugriffsrechte gegenüber einem Zielsystem repräsentieren.

Damit verlagert sich ein Teil der Sicherheitsarbeit. Ein Angreifer, der einen gültigen Nachweis stehlen, fälschen oder wiederverwenden kann, muss den ursprünglichen Login unter Umständen gar nicht noch einmal durchlaufen. Bei einer SSO-Architektur gehört deshalb neben der Anmeldung auch der weitere Umgang mit diesen Nachweisen in die Sicherheitsprüfung.

NIST hat dazu am 15. September 2026 die IR 8587 finalisiert. Die Veröffentlichung richtet sich vor allem an US-Bundesbehörden und Cloud-Anbieter, bündelt aber technische Schutzprinzipien, die auch darüber hinaus relevant sind: Schlüsselmanagement, Verifikation, Gültigkeit, Widerruf und Monitoring von Tokens und Assertions.

Nach der Anmeldung braucht eine Anwendung einen Nachweis

Ein zentraler Login funktioniert nur, wenn nachgelagerte Anwendungen dem Ergebnis dieser Anmeldung vertrauen können. Dafür werden je nach Protokoll unterschiedliche Nachweise verwendet. SAML arbeitet mit Assertions, OAuth mit Access und Refresh Tokens, OpenID Connect ergänzt unter anderem ID Tokens. Dazu kommen anwendungseigene Session-Cookies und andere Sitzungsartefakte.

Diese Formate haben unterschiedliche Aufgaben und Sicherheitsmodelle. Gemeinsam ist ihnen, dass ein Zielsystem entscheiden muss, ob es einen vorgelegten Nachweis akzeptiert. Wer hat ihn ausgestellt? Für welche Anwendung ist er gedacht? Für welche Identität und welchen Zeitraum gilt er? Wurde er verändert? Ist er noch gültig?

NIST SP 800-63C-4 behandelt diese Prüfungen für föderierte Identitäten ausdrücklich. Bei Assertions gehören dazu kryptografische Integrität, die Prüfung des Ausstellers, die vorgesehene Audience, das Subject und ein begrenztes Gültigkeitsfenster. Die sichere Anmeldung ist damit nur der Anfang der Vertrauenskette. Das Ergebnis dieser Anmeldung wird anschließend technisch weitergereicht und muss dabei weiterhin verlässlich bleiben.

MFA schützt den Login, nicht jedes später ausgegebene Token

Mehrfaktor-Authentisierung erschwert es einem Angreifer, sich mit gestohlenen Zugangsdaten selbst anzumelden. Ein bereits ausgegebenes Sitzungs- oder Zugriffstoken liegt an einer anderen Stelle im Ablauf. Bei einem Bearer-Artefakt kann sein Besitz unter den vorgesehenen Bedingungen ausreichen, um es zu verwenden.

NIST beschreibt dieses Risiko für Bearer Assertions ausdrücklich. Wird eine gültige Assertion erfasst und akzeptiert die Relying Party sie weiterhin, kann sie zur Identitätsübernahme gegenüber dieser Anwendung missbraucht werden. Welche Folgen tatsächlich möglich sind, hängt vom konkreten Token, seiner Audience, seiner Gültigkeit und weiteren Schutzmechanismen ab.

Auch aus realen Angriffen gibt es entsprechende Beobachtungen. CISA dokumentierte bei Aktivitäten von APT40 erfasste JSON Web Tokens auf einem kompromittierten System und ordnete sie als Authentifizierungsartefakte ein, die für weitere Sitzungszugriffe beziehungsweise zur Wiederverwendung hätten dienen können. Dieser Fall ist kein Beleg dafür, dass jedes JWT unter allen Bedingungen replaybar ist. Er zeigt aber, warum Token-Diebstahl in Sicherheitsmodellen nicht nur als theoretische Randfrage behandelt wird.

Sechs Kontrollfelder gehören in eine SSO-Prüfung

Für Architektur- und Anbietertermine lässt sich die Guidance sinnvoll in sechs Kontrollfelder übersetzen:

Die praktische Qualität einer Architektur ergibt sich aus dem Zusammenspiel dieser Felder. Ein System mit sehr kurzer Token-Laufzeit kann beispielsweise weiterhin anfällig für unmittelbares Replay sein. Ein sender-gebundenes Token hilft wenig, wenn gleichzeitig das zugehörige Schlüsselmaterial kompromittiert wurde. Und ein sauber signiertes Token bleibt problematisch, wenn eine Anwendung Audience oder Gültigkeit nicht korrekt prüft.

Scope und Audience begrenzen den möglichen Schaden

RFC 9700, die aktuelle IETF Best Current Practice für OAuth 2.0, empfiehlt eine enge Privilegierung von Access Tokens. Ein Token sollte nur die Berechtigungen enthalten, die sein konkreter Anwendungsfall braucht. Auch die Audience sollte auf den vorgesehenen Resource Server oder einen klar definierten Kreis begrenzt sein.

Bei einem Leak entscheidet diese Begrenzung über den möglichen Radius des Schadens. Ein Token für Anwendung A sollte nicht automatisch auch von Anwendung B akzeptiert werden. Ein Nachweis für einen lesenden API-Zugriff braucht keine administrativen Schreibrechte.

In großen Plattformen bedeutet diese Trennung zusätzlichen Architektur- und Pflegeaufwand. Grobe, breit gültige Scopes sind einfacher zu verwalten als viele präzise Berechtigungen. Genau deshalb lohnt es sich, diese Entscheidung sichtbar zu machen: Vereinfachung kann sinnvoll sein, erhöht aber unter Umständen die Reichweite eines kompromittierten Tokens.

Gültigkeitsdauer und Replay-Schutz lösen verschiedene Probleme

Kurze Laufzeiten verkleinern das Zeitfenster, in dem ein gestohlenes Token akzeptiert wird. Innerhalb dieses Fensters kann ein gültiges Bearer Token dennoch nutzbar sein. Die Laufzeit begrenzt also die Dauer des Risikos, während Replay-Schutz darauf zielt, die Nutzung durch einen anderen Sender zu erschweren.

RFC 9700 empfiehlt für Access Tokens, wo das Design dies unterstützt, sender-constrained Verfahren. Mutual TLS und DPoP sind zwei Beispiele. Der Client muss dann neben dem Token zusätzlich nachweisen, dass er über das zugehörige Schlüsselmaterial verfügt.

Für Refresh Tokens öffentlicher Clients verlangt die BCP entweder eine solche Bindung oder Rotation. Bei Rotation ersetzt der Authorization Server beim Refresh das bisherige Token durch ein neues. Taucht ein bereits verbrauchtes Refresh Token später erneut auf, kann das auf eine Kompromittierung hinweisen.

Auch diese Verfahren haben Grenzen. Wer den Client vollständig kompromittiert und neben dem Token auch das benötigte Schlüsselmaterial kontrolliert, kann die Schutzwirkung teilweise umgehen. NIST und IETF behandeln Token-Sicherheit deshalb als Kombination mehrerer Kontrollen und nicht als Wahl einer einzelnen Technik.

Signing Keys gehören zur eigentlichen Vertrauensbasis

Signierte Tokens und Assertions sind nur so vertrauenswürdig wie die Schlüssel und Prüfprozesse dahinter. Eine Relying Party akzeptiert eine Assertion, weil sie dem Aussteller vertraut und dessen Signatur mit dem erwarteten Schlüssel verifizieren kann.

Wird ein Signing Key kompromittiert, ändert sich die Größenordnung des Problems. Dann kann es nicht nur um ein einzelnes gestohlenes Token gehen, sondern um die Möglichkeit, neue Nachweise zu erzeugen, die für Zielsysteme legitim aussehen.

Die finale NIST IR 8587 widmet Schutz und Nutzung von Signing Keys deshalb besondere Aufmerksamkeit. Gegenüber dem Entwurf wurde die Guidance an dieser Stelle überarbeitet. NIST unterscheidet stärker zwischen sicherer Speicherung und sicherer Nutzung der Schlüssel und richtet Entscheidungen über Gültigkeit und Rotation stärker an Systemklassifikation und Sensitivität der betroffenen Transaktionen aus.

Für eine Architekturprüfung ist daher weniger eine pauschale Rotationsfrist interessant als der vollständige Prozess: Wie werden Schlüssel erzeugt, geschützt und verwendet? Wer kann darauf zugreifen? Wie läuft eine Rotation? Wie werden alte Schlüssel aus dem Vertrauen entfernt? Und wie lässt sich im Kompromittierungsfall schnell reagieren?

Widerruf und Telemetrie bestimmen die Reaktionsfähigkeit

Bei einem Sicherheitsvorfall reicht es nicht zu wissen, dass ein Token problematisch ist. Relevant wird, wie schnell und wie vollständig sich das bereits ausgegebene Vertrauen zurücknehmen lässt. Das kann einzelne Sessions, Tokens, Token-Familien oder Schlüssel betreffen.

Verteilte Systeme machen diesen Punkt technisch schwierig. Sie skalieren unter anderem deshalb gut, weil nicht jede Anfrage gegen einen zentralen Zustand geprüft werden muss. Zusätzliche Statusabfragen, Revocation-Mechanismen oder Risikosignale können die Reaktionsfähigkeit verbessern, erhöhen aber je nach Architektur Latenz, Integrationsaufwand oder Abhängigkeiten.

NIST hat in der finalen IR 8587 weitere Referenzen zu Revocation und zum Austausch von Status- und Risikosignalen aufgenommen. Für den Betrieb kommt die Beobachtbarkeit hinzu. CISA nennt begrenzte Telemetrie und kurze Log-Aufbewahrung als konkrete Schwierigkeiten bei der Untersuchung von gefälschten Tokens, kompromittierten Schlüsseln und unautorisierter Token-Erzeugung.

Eine belastbare Architektur braucht daher genügend Informationen, um Auffälligkeiten zu erkennen und nach einem Vorfall nachvollziehen zu können, welche Identität, Anwendung, Session und Schlüssel betroffen waren.

Was bei einer SaaS- oder SSO-Prüfung zusätzlich gefragt werden sollte

„SSO und MFA vorhanden“ bleibt eine sinnvolle Grundanforderung. Für sicherheitsrelevante Anwendungen sollte die Prüfung danach weitergehen:

• Welche Token- und Assertion-Typen verwendet die Architektur für Browser, APIs und Workloads?
• Welche Zielsysteme und Berechtigungen sind in Scope und Audience eines Tokens enthalten?
• Wie werden Laufzeiten für Access-, Refresh- und Session-Artefakte festgelegt?
• Unterstützt die Architektur Replay-Schutz oder sender-gebundene Tokens dort, wo das Risikomodell dies sinnvoll macht?
• Wie werden Signing Keys gespeichert, genutzt, rotiert und bei einer Kompromittierung ersetzt?
• Welche Möglichkeiten bestehen für Session- und Token-Revocation?
• Welche Logs stehen dem Security-Betrieb für Token-Ausgabe, Validierung, ungewöhnliche Zugriffe und administrative Änderungen zur Verfügung?
• Was geschieht bei Rollenänderung, Offboarding oder einem akuten Security Incident mit bereits bestehenden Sessions?

Der letzte Punkt berührt den Benutzer-Lifecycle, den ein SSO-Projekt ebenfalls sauber lösen muss. Provisioning entscheidet, ob ein Konto und seine Rollen noch bestehen sollen. Token- und Session-Kontrollen regeln zusätzlich, wie bereits ausgegebenes Vertrauen endet. Beide Ebenen greifen ineinander, beantworten aber unterschiedliche Fragen.

SSO-Sicherheit endet nicht am Identity Provider

SSO kann Authentifizierung zentralisieren, MFA konsistenter machen und die Zahl verteilter Zugangsdaten reduzieren. Die NIST-Guidance stellt diesen Nutzen nicht infrage. Sie lenkt den Blick auf den Teil der Architektur, der nach einer erfolgreichen Anmeldung weiterarbeitet.

Für eine belastbare Bewertung gehören deshalb zwei Perspektiven zusammen: Wie entsteht Vertrauen in eine Identität? Und wie wird dieses Vertrauen anschließend durch Tokens, Assertions und Sessions weitergegeben, begrenzt und wieder entzogen?

Wer nur die erste Frage prüft, bewertet den Login. Wer beide prüft, bewertet die SSO-Vertrauenskette.