English
Deutsch
PolskiJSON Web Tokens: Aufbau, was in die Nutzlast gehört und der Unterschied zwischen Dekodieren und Prüfen
Inhalt
Ein JSON Web Token sieht verschlüsselt aus. Es ist eine lange Zeichenfolge ohne lesbare Wörter, es steht in einem Authorization-Header, und es wird wie ein Geheimnis behandelt. Was es tatsächlich ist: zwei JSON-Objekte in Base64, dazu eine Signatur – und Base64 ist eine Kodierung, kein Schloss.
Die Folge ist kurz. Alles im Rumpf liest jeder, der das Token hat: der Browser, an den es ging, der Proxy, durch den es lief, die Protokolldatei, die die Adresse festhielt, und das Ticket, in das es jemand hineinkopiert hat. Das ist kein Mangel, sondern die Bauart des Formats. Zum Problem wird es erst, wenn der Rumpf geschrieben wird, als läse niemand mit.
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 trägt die Ansprüche – über wen das Token spricht, was es erlaubt, 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.
exp ist das Einzige, das ein Token beendet
Ein Token gilt, weil es das von sich behauptet. Es gibt keinen Zustand auf dem Server, der es beendet: einmal ausgestellt, wirkt es, bis der Anspruch exp verstrichen ist, und ein Token ohne exp wirkt für immer.
Deshalb macht das Abmelden nichts ungültig. Der Client verwirft das Token, das Token bleibt gültig, und wer eine Kopie behalten hat, behält den Zugang. Ein Token vor seiner Zeit zu beenden verlangt eine Sperrliste, die jeder Dienst prüft – womit genau der gemeinsame Zustand zurückkommt, den das Format vermeiden sollte.
Die brauchbare Anordnung ist ein kurzlebiges Zugriffstoken und ein zentral widerrufbares Auffrischungstoken. Minuten für das erste und für das zweite eine Laufzeit, die tatsächlich jemand im Blick hat: ein Auffrischungstoken mit einem Jahr Gültigkeit ist ein Passwort mit Zwischenschritten.
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.
Passend dazu
