---
id: CP-195
slug: jwt-json-web-token-signatur-fallstricke
lang: de
title: JSON Web Token (JWT)
description: Ein JWT ist der Nachweis, den eine Anwendung nach Ihrer Anmeldung ausstellt. Was die Signatur prüft, welche Fallstricke es gibt und was zu tun ist.
canonical_url: https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke/
markdown_url: https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke.md
publisher: Brain (https://startbrain.io)
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
cite_as: Brain, „JSON Web Token (JWT)“, Cyberpedia, 2026. https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke/ (CC BY 4.0)
wing: 3
theme: control_access
reflex: cr-027
schema: G3
updated: "2026-11-03"
translations:
  de: https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke/
  fr: https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges/
  en: https://startbrain.io/cyberpedia/en/articles/jwt-json-web-token-signature-pitfalls/
  es: https://startbrain.io/cyberpedia/es/articles/jwt-json-web-token-firma-trampas/
sources:
  - "n": 1
    title: Tokens and claims overview - Microsoft identity platform
    publisher: Microsoft
    url: https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens
    published: "2025-03-21"
    accessed: "2026-11-03"
  - "n": 2
    title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®"
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1550/001/
    accessed: "2026-11-03"
  - "n": 3
    title: Access tokens in the Microsoft identity platform - Microsoft identity platform
    publisher: Microsoft
    url: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens
    published: "2025-05-14"
    accessed: "2026-11-03"
  - "n": 4
    title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1528/
    accessed: "2026-11-03"
  - "n": 5
    title: Authentication - OWASP Cheat Sheet Series
    publisher: OWASP
    url: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
    accessed: "2026-11-03"
  - "n": 6
    title: Session Management - OWASP Cheat Sheet Series
    publisher: OWASP
    url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
    accessed: "2026-11-03"
  - "n": 7
    title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1539/
    accessed: "2026-11-03"
---

# JSON Web Token (JWT)

Nach Ihrer Anmeldung an einer Unternehmensanwendung stellt diese Ihnen einen digitalen Nachweis aus, den Ihr Browser oder Ihre Anwendung danach bei jeder Anfrage vorlegt. Bei Microsoft hat dieser Nachweis die Form eines JSON Web Tokens, kurz JWT, das „Claims“ enthält, also Aussagen über den Benutzer oder die Anwendung [1].

Ein JWT lässt sich dekodieren, zum Beispiel mit der Website jwt.ms, und seine Signatur dient dazu, die Echtheit des Tokens zu prüfen [3]. Dieser Beitrag beschreibt, was Beschäftigte tun, und was Verantwortliche tun.

## In 30 Sekunden

- Wo es vorkommt: bei der Microsoft-Identitätsplattform, die Benutzer authentifiziert und Zugriffs-, Aktualisierungs- und Identitätstoken bereitstellt [1].
- Was der Angreifer will: ein gültiges Token stehlen, um mit den Rechten seines Inhabers zu handeln, ohne das Passwort zu kennen [2].
- Der Reflex: ein Token oder eine Adresse, die eines enthält, niemals versenden oder veröffentlichen, sich nach der Nutzung abmelden und jedes ungewöhnliche Verhalten melden.
- Wenn es schon passiert ist: abmelden und dann die IT-Abteilung informieren. OWASP weist darauf hin, dass das Löschen eines Cookies nicht genügt: „deleting a cookie alone does not invalidate a stolen copy of the session ID“, und die Ungültigmachung auf der Serverseite ist nötig [6].

## Direkte Fragen

### Was ist ein JWT?

Ein JWT besteht aus drei durch einen Punkt getrennten Segmenten: dem Header, dem Body und der Signatur [3]. Der Body enthält die Claims. Die Signatur dient dazu, die Echtheit des Tokens zu beurteilen [3].

### Verhindert die Signatur, dass man das Token lesen kann?

Die Signatur dient dazu, die Echtheit des Tokens zu prüfen. Microsoft gibt an, dass Entwickler ein JWT mit einer Website wie jwt.ms dekodieren können, zur Validierung und zur Fehlersuche [3]. Das Token ist sensibel und stellt ein Sicherheitsrisiko dar, wenn es falsch gehandhabt wird [3].

### Kann man mit einem gestohlenen Token wirklich an meiner Stelle handeln?

Ja. MITRE beschreibt Angreifer, die gestohlene Zugriffstoken verwenden, um den üblichen Authentifizierungsprozess zu umgehen und auf Konten, Informationen oder Dienste zuzugreifen. Diese Token werden anstelle der Anmeldedaten verwendet [2].

### Bleibt ein gestohlenes Token lange gültig?

Das hängt von seiner Lebensdauer ab. Bei Microsoft-Zugriffstoken liegt die Standarddauer bei einem Zufallswert zwischen 60 und 90 Minuten, im Mittel 75 Minuten [3]. Mandanten ohne bedingten Zugriff haben für Clients wie Microsoft Teams und Microsoft 365 eine Standarddauer von zwei Stunden [3]. MITRE weist jedoch darauf hin, dass der Angreifer manchmal auch ein Aktualisierungstoken stehlen kann, mit dem er neue Zugriffstoken erhält, ohne den Benutzer einzubeziehen [4].

## Wie es funktioniert

Der Autorisierungsserver signiert das Token mit einem privaten Schlüssel und veröffentlicht den passenden öffentlichen Schlüssel. Um ein Token zu validieren, prüft die Anwendung die Signatur mit diesem öffentlichen Schlüssel [1]. Der Header des JWT nennt den Signaturalgorithmus (Claim `alg`) und den zu verwendenden öffentlichen Schlüssel (Claim `kid`) [3]. Microsoft Entra ID stellt Token aus, die mit standardmäßigen asymmetrischen Algorithmen wie RS256 signiert sind [3].

Das Zugriffstoken wird an eine API als „Bearer“-Token im Authorization-Header übergeben [1]. Weil Token nur für begrenzte Zeit gültig sind, liefert der Server oft ein Paar: ein Zugriffstoken und ein Aktualisierungstoken, das dazu dient, das erste zu erneuern, wenn es sich dem Ablauf nähert [1]. Das Aktualisierungstoken liefert nur dann ein neues Zugriffstoken, wenn der Benutzer weiterhin autorisiert ist [1].

Bei OpenID Connect ist das ID Token ein signiertes JWT, mit dem eine Anwendung die Identität des Benutzers überprüfen kann [5].

## Was Sie tun

Als Beschäftigte oder Beschäftigter:

- Senden Sie niemals ein Token oder eine Webadresse, die eines enthält, in einer Nachricht, einem Ticket oder einem Forum. Sitzungskennungen in einer Adresse können in Links, Protokollen, im Browserverlauf, in Lesezeichen, im Referer-Header oder in Suchmaschinen landen [6].
- Melden Sie sich ab, wenn Sie fertig sind. Eine Anwendung muss eine sichtbare und zugängliche Abmeldeschaltfläche bieten, damit der Benutzer seine Sitzung jederzeit beenden kann [6].
- Verlassen Sie sich nicht darauf, den Browser zu schließen: Das erzwingt eine Abmeldung nicht zuverlässig, insbesondere auf Mobilgeräten [6].
- Melden Sie ungewöhnliches Verhalten (unerwartete Abmeldungen, Aktionen, die Sie nicht ausgeführt haben, die Aufforderung, eine unbekannte Anwendung zu autorisieren). MITRE beschreibt Angreifer, die einer bösartigen Anwendung Zugriff verschaffen lassen, indem sie einen gezielten Phishing-Link versenden [4].

Als Verantwortlicher, von Teams und Lieferanten einzufordern:

- Die Validierung der Signatur und des Ausstellers durch die Anwendung, die das Token empfängt, mit den Werten aus dem OpenID-Discovery-Dokument [3].
- Die Prüfung der Zielgruppe (Audience): Eine API darf nur Token akzeptieren, deren Claim `aud` zu ihr passt. Ein für eine andere Ressource bestimmtes Token zu akzeptieren, ist ein Beispiel für das „Confused-Deputy“-Problem [3].
- Bewährte Bibliotheken statt selbst geschriebenem Code. Microsoft empfiehlt seine MSAL-Bibliotheken, die das Beschaffen, Aktualisieren und Validieren von Token übernehmen [1].
- Begrenzte Sitzungsdauern. OWASP nennt als übliche Bereiche für das Inaktivitäts-Timeout 2 bis 5 Minuten für Anwendungen mit hohem Wert und 15 bis 30 Minuten für solche mit geringem Risiko und verlangt außerdem ein absolutes Timeout unabhängig von der Aktivität [6].
- Eine sorgfältige Speicherung im Browser (siehe nächsten Abschnitt).

## Die Fallstricke

MITRE gibt an, dass gestohlene Token „used in lieu of login credentials“ werden, also anstelle der Anmeldedaten [2]. MITRE weist darauf hin, dass Sitzungscookies bestimmte Protokolle der Multi-Faktor-Authentifizierung umgehen können [7].

In den Quellen kehren mehrere Implementierungsfehler wieder.

- Die Speicherung im Browser. OWASP rät davon ab, Authentifizierungstoken, Sitzungskennungen, JWT oder Aktualisierungstoken in localStorage oder sessionStorage zu speichern: Diese Speicherbereiche sind für jedes JavaScript zugänglich, das im selben Origin läuft, sodass schon eine einzige XSS-Schwachstelle alle Token preisgibt [6]. OWASP bevorzugt Cookies mit HttpOnly, Secure und SameSite=Strict oder ein Modell vom Typ Backend-for-Frontend [6].
- Das Token in der Adresse. Eine über die URL übergebene Kennung kann abfließen und weitere Angriffe wie die Session Fixation erleichtern [6].
- Eine Validierung an der falschen Stelle. Laut Microsoft darf ein Client nicht versuchen, ein Zugriffstoken zu validieren: Das ist Aufgabe der API, und der Client behandelt es als undurchsichtige Zeichenfolge [3].
- Das Vertrauen in den Inhalt, ohne die Signatur zu prüfen. Eine Anwendung, die ein Token validieren muss, prüft zuerst die Signatur und den Aussteller [3].
- Aus der Infrastruktur entwendete Token. In Kubernetes-Umgebungen oder in Pipelines für kontinuierliche Integration und Bereitstellung können API-Token gestohlen werden, wenn der Container oder die Pipeline kompromittiert ist [4].
- Der Diebstahl von Sitzungen durch ein bösartiges Skript oder einen Phishing-Proxy. MITRE nennt Schadsoftware, die auf Browser-Cookies abzielt, und freie Werkzeuge wie Evilginx2 und Muraena, die Cookies über einen bösartigen Proxy abgreifen [7].

Die hier zitierten Quellen beschreiben andere häufig genannte Konstruktionsfehler nicht im Einzelnen, etwa den Algorithmus „none“, die Verwechslung von Schlüsseln oder schwache Geheimnisse. Dieser Punkt sollte von den Entwicklungsteams anhand ihrer eigenen Referenzdokumente überprüft werden.

## Quellen

1. Microsoft, „Tokens and claims overview - Microsoft identity platform“, 21. März 2025. https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens (abgerufen am 3. November 2026)
2. MITRE ATT&CK, „Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1550/001/ (abgerufen am 3. November 2026)
3. Microsoft, „Access tokens in the Microsoft identity platform - Microsoft identity platform“, 14. Mai 2025. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (abgerufen am 3. November 2026)
4. MITRE ATT&CK, „Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1528/ (abgerufen am 3. November 2026)
5. OWASP, „Authentication - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html (abgerufen am 3. November 2026)
6. OWASP, „Session Management - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (abgerufen am 3. November 2026)
7. MITRE ATT&CK, „Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1539/ (abgerufen am 3. November 2026)

---

Originalquelle: Cyberpedia, die öffentliche Enzyklopädie zu Cybersicherheit und KI von Brain. Kanonische Version: https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke/
Sie dürfen diesen Text unter der Lizenz CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) frei weiterverwenden, sofern Sie „Brain, Cyberpedia“ mit einem Link auf die obige Adresse nennen.
