English
Deutsch
PolskiJSON Web Tokens: Aufbau, was in die Nutzlast gehört und der Unterschied zwischen Dekodieren und Prüfen
Inhalt
Du möchtest wissen, was in einem Token steht? Bei einem signierten JWT lässt sich der Inhalt oft schnell ansehen. Die wichtigere Frage kommt danach: Welche dieser Angaben darf eine Anwendung tatsächlich verwenden?
Dieser Artikel behandelt die verbreitete signierte JWS-Form mit drei Teilen. Header und Nutzlast sind dabei Base64url-kodiert, nicht verschlüsselt. Verschlüsselte JWTs (JWE) sind eine andere Form. Wir trennen hier deshalb das Lesen eines Tokens von seiner Prüfung.
Die drei Teile und was jeder leistet
Ein Token besteht aus drei durch Punkte getrennten Abschnitten. Der erste nennt das Verfahren und oft den verwendeten Schlüssel. Der zweite enthält die Claims: Angaben darüber, auf wen sich das Token bezieht, was es erlaubt und wie lange es gilt. Der dritte ist die Signatur über die ersten beiden.
Allein der dritte schützt etwas, und er schützt genau eine Eigenschaft: dass die ersten beiden seit dem Unterschreiben unverändert sind. Er verbirgt sie nicht, und es braucht ihn nicht zu verstehen, um sie zu lesen. Ein Token in einen beliebigen Decoder eingefügt gibt seinen Inhalt sofort preis.
Was im Rumpf nichts zu suchen hat
Jedes Feld im Rumpf ist ein Feld, das dem Besitzer des Tokens ausgehändigt wird. Eine E-Mail-Adresse, ein vollständiger Name, ein Geburtsdatum – damit wird aus einem Ausweis eine Datenweitergabe, und sie landet an Orten, die Ausweise erreichen und personenbezogene Daten nicht sollten: Proxy-Protokolle, Browserspeicher, Fehlerberichte.
Die zweite Sorte ist innere Struktur. Eine Rollenliste wie billing_admin oder eine Mandantennummer verrät, was hinter der Schnittstelle existiert und wie es geordnet ist – genau das, was ein Angreifer zuerst aufzählt. Ein knapper Betreff und ein Bereich genügen meist; der Rest gehört in die Abfrage, die der Server ohnehin macht.
Die dritte ist alles, was nur für den Aussteller gedacht war. Tokens werden in Tickets kopiert, und ein Rumpf mit einer internen Kundennummer wandert mit.
Ablaufzeit und serverseitige Regeln
exp legt eine Ablaufzeit fest. Ohne dieses Feld ist ein Token nicht automatisch unbegrenzt gültig: Die Anwendung kann es verlangen und weitere Regeln prüfen.
Nur das Löschen im Browser widerruft vorhandene Kopien nicht. Eine frühere Sperre braucht eine serverseitige Strategie, etwa eine Sperrliste. Maßgeblich ist die Prüfung durch den empfangenden Dienst. RFC 7519: exp.
Kurzlebige Zugriffstokens und zentral widerrufbare Auffrischungstokens sind ein möglicher Aufbau. Welche Laufzeiten passen, hängt von der Anwendung und ihrer Widerrufsstrategie ab.
Wo Lesen mit Prüfen verwechselt wird
Ein Token zu lesen und ihm zu trauen sind verschiedene Vorgänge, und der Unterschied ist ein Bibliotheksaufruf. Ein Decoder zeigt die Ansprüche jedes Tokens, auch eines, das vor drei Sekunden von Hand geschrieben wurde. Die Prüfung rechnet die Signatur gegen einen Schlüssel nach, und erst sie beantwortet, ob die Ansprüche von jemandem stammen, der sie ausstellen durfte.
Aus der Verwechslung folgen zwei Fehlerbilder. Das erste ist alg: none – ein Token, das erklärt, es habe keine Signatur. Ein Prüfer, der das Verfahren aus dem Token liest und sich daran hält, nimmt alles an; das Verfahren muss die Anwendung festlegen und nicht das Token. Das zweite ist derselbe Fehler mit einem Schlüssel: ein Dienst, der RS256 erwartet und ein HS256-Token bekommt, lässt sich dazu bringen, es mit dem öffentlichen Schlüssel als gemeinsamem Geheimnis zu prüfen – und der öffentliche Schlüssel ist öffentlich.
Was in jedes Token gehört
Auf drei Ansprüche lohnt es zu bestehen. exp, weil ohne ihn nichts endet. iss, damit ein Dienst erkennt, von welchem Aussteller ein Token kommt, statt alles anzunehmen, was sich prüfen lässt. Und aud – jener Anspruch, der verhindert, dass ein für die Berichtsschnittstelle ausgestelltes Token von der Abrechnungsschnittstelle angenommen wird; eine Prüfung, die sich leicht auslassen und schwer vermissen lässt.
Für nichts davon braucht es Werkzeug im großen Stil. Ein Token an seinen Punkten zu teilen und den mittleren Teil zu entschlüsseln dauert Sekunden und beantwortet die Fragen, die sonst durch Annahme beantwortet werden: wie lange das gilt, was es erlaubt und was es jedem verrät, der es liest.
Fragen und Antworten
Was geschieht mit ausgestellten Tokens, wenn der Signaturschlüssel gewechselt wird?
Die bereits ausgestellten Tokens gelten so lange weiter, wie der Prüfer den alten Schlüssel noch kennt. Die Signatur wird gegen einen Schlüssel aus seiner eigenen Liste nachgerechnet, meist gegen den, den der erste Teil des Tokens benennt. Verschwindet dieser Schlüssel aus der Liste, scheitert jedes damit unterschriebene Token auf einen Schlag, gleichgültig, was in exp steht.
Für einen geplanten Wechsel ergibt sich daraus eine Reihenfolge. Zuerst lernen die Prüfer den neuen Schlüssel kennen, dann unterschreibt der Aussteller mit ihm, und der alte bleibt hinterlegt, bis das letzte mit ihm ausgestellte Token abgelaufen ist. Bei Zugriffstokens mit Minuten Laufzeit ist das eine kurze Überlappung; werden auch die Auffrischungstokens als signierte Tokens ausgestellt, reicht sie so weit wie deren Laufzeit.
Umgekehrt beendet das Entfernen eines Schlüssels alle mit ihm unterschriebenen Tokens vor ihrer Zeit, ganz ohne Sperrliste. Das ist der richtige Schritt, wenn der Signaturschlüssel in falsche Hände geraten ist, trifft aber alle Clients zugleich. In jedem Fall darf die Schlüsselangabe im Token nur unter den Schlüsseln auswählen, die der Prüfer selbst hinterlegt hat, aus demselben Grund, aus dem das Verfahren nicht aus dem Token kommen darf.
Lässt sich die Nutzlast verschlüsseln, statt sie knapp zu halten?
Ja, mit JSON Web Encryption nach RFC 7516; dann liest den Inhalt nur, wer den Schlüssel hat. Ein Zugang bleibt das Token trotzdem: Eine Kopie im Ticket oder in einer Protokolldatei ist dann unlesbar, bis zum Ablauf von exp aber genauso verwendbar wie vorher. Ein Feld, das der Server ohnehin nachschlagen kann, braucht deshalb keine Verschlüsselung, sondern gar keinen Platz im Token.
Was bedeutet es für exp, wenn die Uhren der beteiligten Server voneinander abweichen?
exp ist ein Zeitpunkt, und verglichen wird er mit der Uhr des prüfenden Dienstes, nicht mit der des Ausstellers. Geht diese Uhr nach, nimmt der Dienst ein Token noch an, das bereits abgelaufen ist. Geht sie vor, verkürzt sich die Laufzeit um die Abweichung, und bei einem Zugriffstoken von wenigen Minuten ist schon eine Minute ein spürbarer Teil davon. Bei nbf, dem Zeitpunkt, ab dem ein Token gilt, wirkt die Abweichung in umgekehrter Richtung: Ein Dienst mit nachgehender Uhr lehnt ein eben ausgestelltes Token als noch nicht gültig ab.
RFC 7519 lässt dafür eine kleine Toleranz zu, üblicherweise nicht mehr als wenige Minuten, und die meisten Bibliotheken bieten eine Einstellung dafür. Die Toleranz verlängert allerdings jedes Token um genau diesen Betrag, und zwei Minuten auf ein Zugriffstoken mit fünf Minuten Laufzeit sind keine Nebensache. Verlässlicher ist es, alle beteiligten Rechner per NTP zu stellen und die Toleranz bei wenigen Sekunden zu belassen.
Verstehen durch Ausprobieren
Eine Minute: Findest Du den Denkfehler?
Du dekodierst ein JWT und liest role: admin. Was weißt Du sicher?
Dekodieren macht die Nutzlast lesbar. Vertrauen erfordert passende kryptografische Prüfung und erwartete Claims wie Aussteller, Zielgruppe und Ablaufzeit. Die Anwendung entscheidet über Berechtigungen.
Ein Problem, ein nachvollziehbarer Weg
Was steckt in diesem Token?
- Verstehen: JWT verstehen
- Ausprobieren: Demo-Token untersuchen
- Ein Demo-Token ansehen und seine Felder verstehen. Lesbare Angaben belegen noch keine gültige Signatur und keine Berechtigung.
Passend dazu
