Authentifizierungstoken: Typen, Verwendungszwecke & Best Practices

Authentifizierungstoken verifizieren Identitäten, aber gestohlene Token umgehen Sicherheitsmaßnahmen. Erfahren Sie mehr über JWT, OAuth 2.0, SAML und Hardware-Token, häufige Fehler und Verteidigungsstrategien. Sehen Sie, wie SentinelOne identitätsbasierte Angriffe in Active Directory und Entra ID erkennt.

Was ist ein Authentifizierungstoken?

Stellen Sie sich Folgendes vor: Sie melden sich um 9 Uhr morgens in New York bei Ihrer Unternehmensanwendung an. Dreißig Minuten später greift jemand aus Tokio auf Ihr Konto zu. Ihr Passwort wurde nie geändert. Ihr Multi-Faktor-Authentifizierungs-Token (MFA) lag weiterhin auf Ihrem Schreibtisch. Doch ein Angreifer ist gerade mit einem gestohlenen Authentifizierungstoken durch Ihre Haustür gegangen.

Authentifizierungstoken sind die digitalen Ausweise, die Ihre Identität über Unternehmenssysteme hinweg verifizieren. Es handelt sich um kryptografische Anmeldedaten, sodass Ihr Passwort nie mit der Anfrage übertragen wird. Laut NIST Special Publication 800-63B-4 bilden diese Token die Grundlage der digitalen Identitätssicherung in modernen Cybersicherheitsarchitekturen.

Das obige Szenario ist nicht hypothetisch. Im Jahr 2023 zog ein Threat Actor Sitzungstoken aus Support-Dateien, die in Okta's customer support system hochgeladen wurden, und nutzte sie, um die aktiven Sitzungen von fünf Kunden zu kapern. Es wurde kein Passwort geknackt. Keine MFA-Abfrage wurde beantwortet. Ein gültiges Token wurde vorgelegt, und das System tat genau das, wofür es entwickelt wurde.

Zu verstehen, wie Token funktionieren, wo sie versagen und wie sie geschützt werden, ist der Unterschied zwischen einer Authentifizierungsinfrastruktur, die standhält, und einer Infrastruktur, die einem Angreifer die Schlüssel übergibt. Diese Seite behandelt alle drei Aspekte.

Warum Authentifizierungstoken Sicherheitsziele sind

Token sitzen an der Schnittstelle zwischen Ihrer Identitätssicherheit und der Architektur der Zugriffskontrolle. Wenn Sie sich bei einem System authentifizieren, tragen Sie Ihre tatsächlichen Anmeldedaten nicht bei jeder Anfrage mit sich. Stattdessen erhalten Sie ein Token, das sagt: „Diese Person hat bereits nachgewiesen, wer sie ist.“

Wird ein Token gestohlen, umgeht ein Angreifer die Authentifizierung vollständig. Wird eines gefälscht, gibt er sich als legitimer Benutzer aus. Wird manipuliert, wie ein Token validiert wird, eskaliert er Berechtigungen, ohne jemals über ein autorisiertes Konto zu verfügen.

Die Kosten, wenn hier Fehler gemacht werden, sind gut dokumentiert. IBM's 2026 Cost of a Data Breach Report beziffert die weltweiten durchschnittlichen Kosten einer Datenschutzverletzung auf 4,99 Millionen US-Dollar – ein Rekordhoch. Verizon's 2026 Data Breach Investigations Report (DBIR) stellte fest, dass die Ausnutzung von Schwachstellen erstmals in der 19-jährigen Geschichte des Berichts gestohlene Anmeldedaten als wichtigsten Einstiegspunkt für Sicherheitsverletzungen überholt hat. Anmeldedaten hielten diesen Platz bis zu diesem Jahr, und ein gestohlenes Token ist ein Berechtigungsnachweis, der die Eingangstür bereits passiert hat.

Um diese Risiken zu verstehen, müssen Sicherheitsteams zunächst die verschiedenen Tokentypen erkennen, die Unternehmen einsetzen, und verstehen, wie jeder davon eigene Sicherheitsaspekte mit sich bringt.

Arten von Authentifizierungstoken

Unternehmen setzen je nach Sicherheitsanforderungen und Anwendungsfällen unterschiedliche Tokentypen ein.

• JSON Web Tokens (JWTs): Eigenständige Token, die codierte Claims in einer Header-Payload-Signatur-Struktur enthalten. JWTs ermöglichen zustandslose Verifizierung, bei der Server Token ohne Datenbankabfragen validieren, was sie ideal für verteilte Microservices-Architekturen macht.
• OAuth 2.0 Tokens: Das OAuth-Framework verwendet zwei Tokentypen, die zusammenarbeiten. Access Tokens stellen kurzlebige Anmeldedaten für API-Aufrufe bereit, während Refresh Tokens neue Access Tokens ohne erneute Authentifizierung beziehen. Diese Trennung begrenzt den Schaden durch Tokendiebstahl.
• SAML (Security Assertion Markup Language) Assertions: XML-basierte Token, die zwischen Identitätsanbietern und Dienstanbietern für Enterprise Single Sign-On ausgetauscht werden. SAML bleibt in Legacy-Unternehmensumgebungen und B2B-Föderationsszenarien dominant.
• Sitzungstoken: Vom Server generierte Kennungen, die Browser mit serverseitigem Sitzungsstatus verknüpfen. Im Gegensatz zu zustandslosen JWTs erfordern Sitzungstoken Serverspeicherung, bieten aber sofortige Widerrufsmöglichkeiten.
• FIDO2/Hardware-Tokens: Physische Authentifikatoren, die Public-Key-Kryptografie über WebAuthn-APIs verwenden. Diese Token bieten Phishing-Resistenz durch kryptografische Ursprungsbindung und stellen sicher, dass Anmeldedaten nur auf legitimen Websites funktionieren.

Während jeder Tokentyp unterschiedlichen Zwecken dient, teilen sie gemeinsame Architekturelemente, die ihre Sicherheitslage bestimmen. Bei diesen Komponenten beginnt die Härtung.

Kernkomponenten von Authentifizierungstoken

Authentifizierungstoken enthalten spezifische Elemente, die ihre Sicherheitslage und funktionalen Fähigkeiten bestimmen.

1. Token-Struktur: JWTs bestehen aus drei Abschnitten: Header (gibt den Signaturalgorithmus wie RS256 oder ES256 an), Payload (enthält Claims) und Signatur (gewährleistet kryptografische Integrität). SAML Assertions verwenden XML-formatierte Anweisungen gemäß den Spezifikationen von OASIS SAML V2.0.
2. Token-Metadaten: Token tragen Metadaten in ihrer Payload. Ablaufzeitstempel (exp claim) definieren Gültigkeitsfenster, Issued-at-Claims (iat) legen das Tokenalter fest, JWT ID (jti) liefert eindeutige Kennungen für die Nachverfolgung von Widerrufen, und Zielgruppenbeschränkungen (aud claim) verhindern die Wiederverwendung von Token über Dienste hinweg.
3. Sitzungsentropie: Sitzungstoken für Webanwendungen erfordern eine Mindestentropie, die durch kryptografisch sichere pseudorandomisierte Zahlengeneratoren (CSPRNGs) erzeugt wird.
4. Hardware-Token-Kryptografie: FIDO2-Token kombinieren WebAuthn-Browser-APIs mit dem Client to Authenticator Protocol (CTAP). Private Schlüssel verlassen nie das sichere Element, und kryptografische Ursprungsbindung stellt sicher, dass Anmeldedaten nur auf legitimen Websites funktionieren.

Diese Komponenten werden zu Workflows kombiniert, und im Workflow entscheidet sich, ob Tokensicherheit gewonnen oder verloren wird. Die folgenden Abschnitte zeichnen jeden Ablauf nach, einschließlich der Interaktion von Token mit der Multi-Faktor-Authentifizierung.

Wie Authentifizierungstoken funktionieren

Authentifizierungstoken folgen je nach Typ und Bereitstellungskontext unterschiedlichen Workflows.

• JWT-Authentifizierungsablauf: Sie übermitteln Anmeldedaten an den Authentifizierungsserver. Der Server validiert die Anmeldedaten, erzeugt und signiert kryptografisch ein JWT mit Ablauf-, Zielgruppen- und Aussteller-Claims und gibt es an Ihren Client zurück. Bei nachfolgenden Anfragen fügen Sie das JWT in den Authorization-Header ein. Der Ressourcenserver validiert die Signatur und überprüft die Claims, bevor er Zugriff gewährt.
• OAuth 2.0 Authorization Code Flow: Sie fordern Zugriff auf eine geschützte Ressource an. Nach Authentifizierung und Zustimmung stellt der Server einen Autorisierungscode aus, den Ihre Anwendung gegen Access Tokens und Refresh Tokens eintauscht. Sie verwenden kurzlebige Access Tokens für API-Aufrufe und tauschen bei Bedarf Refresh Tokens gegen neue Access Tokens aus.
• SAML Web Browser SSO: Sie versuchen, auf eine Dienstanbieteranwendung zuzugreifen, die Sie zum Identitätsanbieter weiterleitet. Nach der Authentifizierung erzeugt der IdP eine signierte SAML Assertion und sendet sie an den Dienstanbieter, wodurch Ihre authentifizierte Sitzung hergestellt und Single Sign-On über mehrere Anwendungen hinweg ermöglicht wird.
• Token-Aktualisierung und -Rotation: Kurzlebige Access Tokens laufen häufig ab und erfordern Aktualisierungsmechanismen. Token-Rotation erzeugt jedes Mal ein neues Refresh Token, wenn Sie eines verwenden, und verhindert so Replay-Angriffe. Wenn jemand ein Refresh Token erneut verwendet, erkennt das System eine mögliche Kompromittierung und kann die gesamte Token-Familie widerrufen.
• Hardware-Token-Authentifizierung: Sie registrieren Ihren FIDO2-Authentifikator, indem Sie ein Schlüsselpaar im sicheren Element des Geräts erzeugen. Während der Authentifizierung sendet der Dienst eine kryptografische Challenge, die Ihr Authentifikator mit dem privaten Schlüssel signiert. Der Dienst verifiziert die Signatur mit dem registrierten öffentlichen Schlüssel.

Korrekt implementiert, rechtfertigen diese Workflows ihre Komplexität. Hier zahlt sich das aus.

Anwendungsfälle für Authentifizierungstoken

Authentifizierungstoken erfüllen spezifische Sicherheits- und Betriebsanforderungen in Unternehmensumgebungen.

1. Enterprise Single Sign-On: SAML Assertions ermöglichen es Mitarbeitern, sich einmal zu authentifizieren und auf Dutzende Anwendungen zuzugreifen, ohne sich wiederholt anmelden zu müssen. Identitätsanbieter wie Okta, Azure AD und Ping Federation stellen Token aus, denen Dienstanbieter vertrauen, wodurch Passwortmüdigkeit reduziert und die Zugriffssteuerung zentralisiert wird.
2. API- und Microservices-Sicherheit: OAuth 2.0 Access Tokens sichern die Service-zu-Service-Kommunikation in verteilten Architekturen. Jeder Microservice validiert eingehende Token unabhängig, was zustandslose Skalierbarkeit ohne gemeinsame Sitzungsspeicher ermöglicht.
3. Autorisierung durch Dritte: OAuth 2.0 ermöglicht Szenarien wie „Login mit Google“, bei denen Benutzer Anwendungen autorisieren, auf ihre Daten zuzugreifen, ohne Passwörter weiterzugeben. Der Autorisierungsserver stellt bereichsbezogene Token aus, die einschränken, worauf Anwendungen zugreifen können.
4. Sitzungen mobiler Anwendungen: JWTs bieten persistente Authentifizierung für mobile Apps. In iOS Keychain oder Android KeyStore gespeicherte Token überstehen App-Neustarts und ermöglichen nahtlose Benutzererfahrungen bei gleichzeitiger Aufrechterhaltung der Sicherheit durch plattformspezifische sichere Speicherung.
5. Machine-to-Machine-Authentifizierung: Automatisierte Systeme und IoT-Geräte verwenden Client-Credentials-Grants, um Token für den API-Zugriff zu erhalten. Diese Token authentifizieren geplante Jobs, Überwachungssysteme und Gerätekommunikation ohne menschliche Interaktion.

Das Muster bleibt bei allen gleich. Token ersetzen die wiederholte Übertragung von Anmeldedaten durch einen Claim, den das empfangende System selbst verifizieren kann.

Wesentliche Vorteile von Authentifizierungstoken

Tokenbasierte Authentifizierung ist der traditionellen Sitzungsverwaltung in vier Punkten überlegen:

1. Zustandslose Skalierbarkeit: Tokenbasierte Systeme beseitigen die Anforderungen an serverseitige Sitzungsspeicherung und ermöglichen Microservices-Architekturen, in denen einzelne Dienste Anmeldedaten unabhängig und ohne gemeinsamen Status verifizieren.
2. Domänenübergreifendes Single Sign-On: SAML 2.0 Assertions und OpenID Connect ermöglichen Single Sign-On. Benutzer authentifizieren sich einmal und greifen auf mehrere Anwendungen zu, ohne sich wiederholt anmelden zu müssen, wodurch die Authentifizierungssteuerung zentralisiert wird.
3. API-Sicherheit und Zero Trust: Service-zu-Service-Authentifizierung mit OAuth 2.0 Client Credentials und signierten JWTs verhindert, dass sich nicht autorisierte Dienste als vertrauenswürdige ausgeben, was für Zero-Trust-Architekturen essenziell ist.
4. Reduzierte Angriffsfläche: Standardbasierte Implementierung schützt vor spezifischen Angriffen. HttpOnly-Cookies verhindern JavaScript-Zugriff. SameSite-Attribute stoppen Cross-Site Request Forgery (CSRF)-Angriffe. FIDO2-Token erreichen Phishing-Resistenz durch kryptografische Ursprungsbindung.

Diese Vorteile gehen jedoch mit Kompromissen einher. Dieselben Architekturentscheidungen, die Skalierbarkeit und Flexibilität ermöglichen, führen auch zu Herausforderungen, die Sicherheitsteams adressieren müssen.

Herausforderungen und Einschränkungen von Authentifizierungstoken

Tokenbasierte Authentifizierung bringt spezifische betriebliche und sicherheitsbezogene Herausforderungen mit sich, die eine sorgfältige Architekturplanung erfordern.

1. Komplexität des Token-Widerrufs: Die zustandslose Natur, die Skalierungsvorteile bietet, schafft Herausforderungen für die sofortige Beendigung von Zugriffen. Zustandslose Token bleiben bis zum Ablauf gültig und erfordern entweder kurze Laufzeiten, die den Aktualisierungsaufwand erhöhen, eine Infrastruktur zur Token-Blacklistung, die die Vorteile der Zustandslosigkeit zunichtemacht, oder die Akzeptanz von Latenzfenstern beim Widerruf.
2. Abwägungen beim Management der Token-Lebensdauer: Kurze Laufzeiten von Access Tokens begrenzen den potenziellen Schaden bei einer Kompromittierung, erfordern jedoch ständige Austausche von Refresh Tokens. Lange Laufzeiten verbessern die Benutzererfahrung, schaffen aber größere Expositionsfenster, wenn Token gestohlen werden.
3. Sichere Tokenspeicherung über Plattformen hinweg: Jedes Skript, das auf der Seite ausgeführt wird, kann localStorage und sessionStorage lesen, sodass eine einzelne Cross-Site Scripting (XSS)-Schwachstelle beide sofort in eine Liste gültiger Token verwandelt. Der weit verbreitete Hybridansatz speichert Refresh Tokens in HttpOnly-Cookies, hält Access Tokens im Speicher und wendet CSRF-Prüfungen auf den Refresh-Endpunkt an. Ein Access Token im Speicher ist auf einem kompromittierten Host weiterhin Speicher-Dumping ausgesetzt – genau dafür gibt es Endpoint Security. Mobile Anwendungen benötigen plattformspezifische Speicherung: Der iOS Keychain speichert Token direkt, während Android sie unter einem Schlüssel verschlüsselt, der im Android Keystore gehalten wird. Server-zu-Server-Kommunikation gehört in ein Secret-Management-System wie HashiCorp Vault oder AWS Secrets Manager.
4. Schlüsselrotation und kryptografisches Management: Schlüsselrotation in Produktionsumgebungen bringt Koordinationskomplexität mit sich. Unternehmen müssen während Rotationsfenstern mehrere gültige Signaturschlüssel vorhalten, die Rotation über verteilte Dienste hinweg koordinieren und die Validierung von Schlüsselkennungen (kid) korrekt handhaben.

Diese Implementierungsherausforderungen schaffen spezifische Schwachstellen, die Angreifer in Unternehmensumgebungen aktiv ausnutzen.

Häufige Implementierungsfehler bei Authentifizierungstoken

Die meisten Sicherheitsverletzungen bei Authentifizierungstoken gehen auf Implementierungsfehler und nicht auf kryptografische Schwächen zurück. Das Verständnis dieser häufigen Fehler hilft Sicherheitsteams, ihre Härtungsmaßnahmen zu priorisieren.

• Unsichere clientseitige Speicherung: Die Speicherung von Authentifizierungstoken in browserbasiertem localStorage oder sessionStorage ist einer der häufigsten Implementierungsfehler. Jeder JavaScript-Code, der im Seitenkontext ausgeführt wird, kann direkt auf Authentifizierungstoken zugreifen und sie exfiltrieren, wodurch sie sofort für XSS-Angriffe anfällig werden.
• Fehler bei der Signaturvalidierung: Wenn JWT-Signaturen nicht korrekt validiert werden, entstehen ausnutzbare Schwachstellen zur Umgehung der Authentifizierung. Algorithmusverwechslungsangriffe manipulieren den Algorithmus-Header von RS256 (asymmetrisch) zu HS256 (symmetrisch) und signieren Token dann mit dem öffentlichen Schlüssel als HMAC-Secret. Verwundbare Systeme akzeptieren diese modifizierten Token und ermöglichen so eine Rechteausweitung. Diese Schwachstelle wurde in CVE-2024-54150 mit einem Schweregrad von CVSS 9.1 CRITICAL dokumentiert. Einige Implementierungen akzeptieren Token mit der Angabe „alg: none“ und verarbeiten damit effektiv unsignierte Token als gültig.
• Übermäßig lange Token-Laufzeiten: Zu lange Token-Laufzeiten schaffen anhaltende Sicherheitsrisiken. Langlebige Token geben Angreifern erweiterte Zeitfenster. Sobald sie durch XSS- oder Man-in-the-Middle-Angriffe kompromittiert wurden, ermöglichen Token mit übermäßigen Laufzeiten unautorisierten Zugriff über Tage oder Wochen statt nur Minuten.
• Fehlende Mechanismen zum Token-Widerruf: Das Fehlen von Möglichkeiten zum Token-Widerruf stellt eine erhebliche Architekturlücke dar. Die Kompromittierung von Primary Refresh Tokens (PRTs), die in SSO-Implementierungen wie Azure AD verwendet werden, ist besonders problematisch. Ohne Widerrufsmechanismen können Unternehmen kompromittierte Sitzungen nicht in Echtzeit beenden und sind auf den natürlichen Tokenablauf angewiesen.
• Unsicheres Schlüsselmanagement: Fehler im Schlüsselmanagement schaffen systemische Schwachstellen. SQL injection-Schwachstellen in Mechanismen zum Abrufen von Schlüsseln können Signaturschlüssel offenlegen, wenn Anwendungen anfällige SQL-Abfragen verwenden, um JWT-Schlüssel über den kid-Parameter abzurufen. Die Speicherung sensibler Informationen in JWT-Payloads schafft unnötige Datenoffenlegung, da JWT-Claims nur base64-codiert (nicht verschlüsselt) sind und daher von jedem mit Tokenzugriff trivial gelesen werden können.

Diese Fehler haben Namen und Daten. Im April 2022 nutzte ein Angreifer OAuth tokens stolen from Heroku and Travis CI, um private Repositories von Dutzenden Organisationen herunterzuladen, darunter npm. Der oben auf dieser Seite beschriebene Diebstahl von Okta-Sitzungstoken funktionierte auf dieselbe Weise: gültige Token, von der falschen Partei vorgelegt, ohne Rückfrage akzeptiert.

Jeder einzelne dieser Fehler ist vermeidbar, und die Kontrollen sind bereits dokumentiert. Defense in Depth auf Basis etablierter Standards schließt die Lücken, auf die Angreifer zählen.

Best Practices für Authentifizierungstoken

Der Schutz von Authentifizierungstoken erfordert die Umsetzung von Defense-in-Depth-Strategien auf Grundlage maßgeblicher Sicherheitsstandards wie NIST SP 800-63B-4, OWASP und IETF-Spezifikationen.

• HttpOnly- und Secure-Cookies einsetzen: Kombinieren Sie in HttpOnly-Cookies gespeicherte Refresh Tokens mit im Speicher gehaltenen Access Tokens. Setzen Sie das HttpOnly-Flag, um JavaScript-Zugriff auf Cookie-Inhalte zu verhindern. Konfigurieren Sie das Secure-Flag, damit die Übertragung nur über HTTPS-Verbindungen erfolgt. Implementieren Sie das SameSite-Attribut zum Schutz vor CSRF.
• Kurzlebige Access Tokens mit Rotation implementieren: Konfigurieren Sie die Laufzeiten von Access Tokens basierend auf Ihrer Risikotoleranz. Token-Rotation erzeugt jedes Mal ein neues Refresh Token, wenn Sie eines verwenden, und verhindert so Replay-Angriffe. Verfolgen Sie alle ausgestellten Refresh Tokens anhand ihrer jti-Claims und invalidieren Sie vorherige Token unmittelbar nach erfolgreicher Rotation.
• Strikte Signaturvalidierung durchsetzen: Lehnen Sie Token mit „alg: none“ im Header explizit ab. Validieren Sie, dass Signaturalgorithmen den erwarteten Typen entsprechen, um RSA/HMAC-Verwechslungsangriffe zu verhindern. Verwenden Sie parametrisierte Abfragen für das Abrufen von Schlüsseln, um SQL-Injection zu verhindern.
• Token Binding einsetzen: Konfigurieren Sie Conditional-Access-Richtlinien zur Durchsetzung von Token Binding, damit Token außerhalb der ursprünglich ausstellenden Geräte durch Trusted Platform Module (TPM)- oder Secure-Enclave-Integration nicht funktionieren können.
• Widerrufsinfrastruktur implementieren: Erstellen Sie eine datenbankgestützte Nachverfolgung von Token-Familien mithilfe von jti-Claims. Schaffen Sie administrative Oberflächen für den Sitzungswiderruf und implementieren Sie eine „Überall abmelden“-Funktion, mit der Benutzer alle Sitzungen widerrufen können, wenn sie eine Kompromittierung vermuten.

Selbst wenn diese Best Practices umgesetzt sind, finden hochentwickelte Angreifer weiterhin Wege, Token zu kompromittieren. Wenn Prävention nicht ausreicht, zählt, wie schnell Sie den Missbrauch erkennen und wie schnell Sie darauf reagieren können.

Wie SentinelOne identitätsbasierte Angriffe erkennt

Singularity™ Platform bietet autonome Erkennung und Reaktion über Ihre Endpunkte, Cloud-Workloads und Identitätsinfrastruktur hinweg. In den 2024 MITRE ATT&CK Evaluations: Enterprise erzielte SentinelOne eine Erkennungsrate von 100 % bei 88 % weniger Warnmeldungen als der Median aller bewerteten Anbieter – das ist der Unterschied zwischen einer Alarmwarteschlange, die Ihre Analysten bearbeiten können, und einer, die sie aufgeben. Purple AI™ beschleunigt die Untersuchung selbst. Analysten fragen in natürlicher Sprache und erhalten kontextbezogene Warnungszusammenfassungen zurück – mit bis zu 80 % schnellerem Threat Hunting.

Singularity Identity schützt Active Directory und Entra ID vor Identitätsbedrohungen. Die Erkennungen reagieren auf Credential-Angriffe, die diese Umgebungen direkt ins Visier nehmen, einschließlich der Verwendung gestohlener und gefälschter Kerberos-Tickets für laterale Bewegung und Rechteausweitung. Die Storyline™-Technologie rekonstruiert den Angriff während seines Ablaufs und korreliert Authentifizierungsereignisse mit Endpunktverhalten. Sie sehen die vollständige Kette, nicht nur eine einzelne Warnung. Wenn eine Erkennung ausgelöst wird, begrenzt die autonome Reaktion die Bedrohung, isoliert den Host und macht den Schaden mit 1-Click rollback rückgängig, bevor Ransomware die Verschlüsselung abschließt. 

Fordern Sie eine Demo von SentinelOne an, um identitätsbasierte Erkennung in Ihrer eigenen Umgebung in Aktion zu sehen.

Tour starten

Erhalten Sie Echtzeitschutz für Identitäten und vollständige Transparenz in hybriden Umgebungen, um Exponierungen zu erkennen, Missbrauch von Anmeldedaten zu stoppen und Identitätsrisiken zu reduzieren.

Wichtigste Erkenntnisse

Das Tokio-Angriffsszenario vom Anfang? Es tritt ein, wenn ein gestohlenes Token die Authentifizierung umgeht, ohne jemals ein Passwort oder eine MFA-Abfrage zu berühren. Falsch konfigurierte Token schaffen reale Risiken, und Token bleiben dennoch essenziell. Jeder Typ hat seine Aufgabe: JWTs für zustandslose Microservices, OAuth 2.0 für API-Autorisierung, SAML für Enterprise SSO und FIDO2 für phishing-resistente Authentifizierung. Jeder einzelne davon wird zu einem Angriffsvektor, wenn er nachlässig implementiert wird.

Die Liste der Abhilfemaßnahmen ist kurz. Speichern Sie Refresh Tokens in HttpOnly-Cookies, halten Sie Access Tokens im Speicher, validieren Sie Signaturen strikt und rotieren Sie bei jeder Aktualisierung. Die meisten der auf dieser Seite beschriebenen Fehler sind genau eines davon, das nicht umgesetzt wurde, plus zwei weitere Punkte, die leichter aufzuschieben als umzusetzen sind: Widerrufsinfrastruktur und Schlüsselmanagement.

Ergänzen Sie XDR sowie Identity Threat Detection and Response (ITDR), damit ein Token in den falschen Händen als Erkennung sichtbar wird und nicht erst sechs Monate später als Audit-Feststellung. CVE-2024-54150 und die acht von Nationalstaaten unterstützten Gruppen, die in MITRE ATT&CK's October 2024 update verfolgt werden, zeigen, dass Tokenausnutzung aktiv und aktuell ist. Die Kontrollen, die sie stoppen, existieren bereits – und Sie können sie einsetzen.

FAQs

Was ist ein Authentifizierungstoken?

Ein Authentifizierungs-Token ist ein kryptografischer Nachweis, der Ihre Identität gegenüber Unternehmenssystemen verifiziert, ohne dass Ihr Benutzername und Ihr Passwort wiederholt übertragen werden müssen. Wenn Sie sich bei einer Anwendung anmelden, stellt der Server ein Token als Nachweis einer erfolgreichen Authentifizierung aus. 

Ihr Gerät übermittelt dieses Token bei jeder nachfolgenden Anfrage, sodass Server Ihre Identität ohne eine zweite Anmeldung verifizieren können. Gängige Formate sind JSON Web Tokens (JWTs), OAuth 2.0-Tokens, SAML-Assertions und FIDO2-Tokens.

Was ist der Unterschied zwischen Access Tokens und Refresh Tokens?

Access-Tokens stellen kurzlebige Anmeldedaten für den Zugriff auf geschützte Ressourcen bereit und laufen gemäß den NIST-Empfehlungen in der Regel innerhalb von Minuten ab. Refresh-Tokens ermöglichen das Abrufen neuer Access-Tokens, wenn aktuelle Tokens ablaufen, ohne dass eine wiederholte Authentifizierung erforderlich ist, und sind in der Regel mehrere Tage bis Wochen gültig. 

Dieser Dual-Token-Ansatz schafft ein Gleichgewicht zwischen Sicherheit durch kurze Lebensdauern von Access-Tokens und Benutzerfreundlichkeit. Die Token-Rotation erzeugt bei jeder Verwendung einen neuen Refresh-Token und macht den vorherigen ungültig, um Replay-Angriffe zu verhindern.

Wie stehlen Angreifer Authentifizierungstoken?

Angreifer stehlen Tokens durch XSS-Angriffe, bei denen Tokens aus localStorage extrahiert werden, Man-in-the-Middle-Angriffe, bei denen die Übertragung abgefangen wird, Memory Dumping auf kompromittierten Endpunkten, die Ausnutzung von CI/CD-Pipelines und CSRF-Sitzungsübernahmen. 

Acht staatlich unterstützte Gruppen, darunter APT28, APT29, APT41, Kimsuky, MuddyWater, OilRig, Sandworm Team und Turla, haben 2024 ihre Fähigkeiten für Token-Angriffe erweitert. Der Schutz erfordert HttpOnly-Cookies, eine sichere Übertragung über HTTPS, die Bindung von Tokens an Geräte und ein verhaltensbasiertes Monitoring, das  anomale Nutzungsmuster erkennt.

Wie sollten Sie Authentifizierungstoken in Webanwendungen speichern?

Speichern Sie Refresh Tokens in HttpOnly-, Secure-, SameSite-Cookies, die JavaScript-Zugriff und CSRF-Angriffe verhindern. Bewahren Sie kurzlebige Access Tokens im Speicher statt in localStorage oder sessionStorage auf, um XSS-basierten Diebstahl zu vermeiden. 

Verwenden Sie für mobile Apps iOS Keychain oder Android KeyStore. Nutzen Sie für die Serverkommunikation Secret-Management-Systeme wie HashiCorp Vault oder AWS Secrets Manager anstelle von Umgebungsvariablen oder Konfigurationsdateien.

Können Authentifizierungstoken für zusätzliche Sicherheit verschlüsselt werden?

JWTs enthalten base64-kodierte Claims, die jeder mit Token-Zugriff lesen kann. Verwenden Sie für sensible Daten JWE (JSON Web Encryption), das Payload-Verschlüsselung durch Standards wie RSA-OAEP-256 oder AES-GCM bereitstellt. 

Eine bessere Praxis besteht jedoch darin, niemals sensible Daten in Token-Payloads einzuschließen. Speichern Sie nur nicht sensible Kennungen wie Benutzer-IDs und Rollen. Bewahren Sie sensible Attribute in Backend-Datenbanken auf und rufen Sie sie serverseitig mithilfe von Token-Kennungen ab.

Was ist Token Binding und wie verbessert es die Sicherheit?

Die Token-Bindung verknüpft Authentifizierungstoken kryptografisch mit dem spezifischen Gerät, auf dem sie ausgestellt wurden, und verhindert so, dass Angreifer gestohlene Token auf anderen Systemen wiederverwenden. Das Token wird durch kryptografische Nachweise an das Trusted Platform Module (TPM) oder die Secure Enclave des Geräts gebunden. 

Wenn das Token vorgelegt wird, überprüft der Server sowohl die Token-Signatur als auch die Gerätebindung. Microsoft Conditional Access und ähnliche Enterprise- Identity-Management-Lösungen unterstützen die Token-Bindung für Umgebungen mit hohen Sicherheitsanforderungen.