Jede Token-Validierung traf unseren Origin. Jetzt lebt das JWKS am Edge.

Um eines unserer JWTs zu validieren, holt sich ein Dienst zwei öffentliche Dokumente vom Issuer: das Discovery-Dokument unter /.well-known/openid-configuration und das JWKS, auf das es verweist – den Satz öffentlicher Schlüssel, mit denen die Tokens signiert sind. Das sind die meistabgefragten und am wenigsten geheimen Dinge, die wir ausliefern. Es sind öffentliche Schlüssel, die per Definition öffentlich sind, und Metadaten, die sich nur ändern, wenn wir rotieren. Und bis vor Kurzem kam jeder einzelne dieser Abrufe den ganzen Weg bis zu unserem Origin zurück. Weil wir mandantenfähig sind, war es schlimmer, als dieser Satz klingen lässt.

Der Origin verrichtete Arbeit, für die es keinen Grund gab

Jeder Mandant ist sein eigener Issuer, mit seinem eigenen .well-known-Dokument und seinem eigenen JWKS. Und jede Relying Party, jeder Resource Server, jedes SDK, das ein Token validiert, ruft diese Dokumente ab – beim Kaltstart, wenn der eigene kurze Cache abläuft, einmal pro Dienstinstanz. Multiplizieren Sie die Issuer pro Mandant mit den Validatoren pro Dienst mit den Cache-Misses, und Sie erhalten einen Schwall von Anfragen wie aus einem Feuerwehrschlauch, der komplett bei der Anwendung ankommt – und das alles für Dokumente, die für jeden Aufrufer Byte für Byte identisch sind und sich nur ändern, wenn wir einen Schlüssel rotieren.

Das ist das Lehrbuchprofil von etwas, das gecacht werden sollte: öffentlich, identisch, selten veränderlich. Stattdessen erzeugte die Anwendung öffentliche Schlüssel dynamisch, mitten auf dem heißen Pfad der Token-Validierung aller anderen. Es gab keinerlei Grund, diese Schlüssel pro Anfrage zu berechnen.

Sie an den Edge bringen

Die Änderung selbst ist klein: Setzen Sie ehrliche Cache-Control-Header auf die Discovery- und JWKS-Antworten, damit Cloudflare sie am Edge cacht. Jetzt trifft ein Validator den nächstgelegenen Cloudflare Point of Presence, und der Origin liefert jedes Dokument nur noch etwa einmal pro PoP pro TTL aus statt einmal pro Validierung. Discovery lässt sich trivial cachen – es ändert sich so gut wie nie. Über das JWKS müssen Sie gründlich nachdenken, denn das JWKS ist genau das eine Dokument, dessen gesamte Aufgabe darin besteht, sich genau dann zu ändern, wenn Sie einen Schlüssel rotieren – und ein Ding zu cachen, das in dem einen Moment frisch sein muss, in dem es sich ändert, ist genau die Stelle, an der man sich selbst ins Knie schießt.

Wie ein gecachtes JWKS Ihnen auf die Füße fällt

Schlüsselrotation plus ein gecachter Schlüsselsatz ist eine Falle, und sie versagt in die denkbar schlechteste Richtung. Rotieren Sie auf einen neuen Signaturschlüssel, beginnen Sie, damit Tokens auszustellen – und ein Validator, der das JWKS vor dem Erscheinen des neuen Schlüssels abgerufen hat, hält eine veraltete Kopie in Händen. Ein Token trifft ein, das die Key-ID des neuen Schlüssels trägt; der Validator schlägt sie nach, findet sie nicht und lehnt das Token ab. Das Token ist vollkommen gültig. Die Signatur ist echt. Der Nutzer hat nichts falsch gemacht. Ihr eigener Edge-Cache hat soeben einem legitimen Login ein 401 zurückgegeben.

Achten Sie darauf, in welche Richtung das schiefgeht. Ein veralteter privater Schlüssel ist ein Nichtereignis – Sie haben den neuen schlicht noch nicht in Gebrauch genommen. Ein veralteter öffentlicher Schlüsselsatz ist ein selbst verschuldeter Ausfall, und den Cache, der ihn verursacht, haben Sie mit Absicht eingeführt, um Origin-Traffic zu sparen. Die Sicherheit des gesamten Schemas steht und fällt mit der Rotation.

Das rotationssichere Muster

Die Sicherheit steckt vollständig in der Reihenfolge, und die Reihenfolge ist das genaue Gegenteil eines atomaren Tauschs. Drei Regeln:

• Veröffentlichen, bevor Sie signieren. Der neue Schlüssel kommt zuerst ins JWKS, und Sie signieren kein einziges Token mit ihm, solange dieses JWKS – neue Key-ID und alles – nicht mindestens eine volle Cache-TTL lang am Edge live war. Bis überhaupt ein Token mit dem neuen Schlüssel einen Validator erreichen kann, enthält der zwischengespeicherte Schlüsselsatz des Validators den Schlüssel bereits.
• Ausmustern nach Ablauf, nicht bei der Rotation. Der alte Schlüssel bleibt im JWKS veröffentlicht, bis das letzte Token, das er je signiert hat, abgelaufen ist. Alt und Neu bestehen während der gesamten Überlappung nebeneinander. Ziehen Sie den alten Schlüssel in dem Moment ab, in dem Sie rotieren, dann lassen Sie jedes noch gültige Token stranden, das er signiert hat.
• TTL kürzer als die Überlappung. Das max-age des Edge-Caches, zuzüglich eines Spielraums für Uhren-Drift, muss kürzer sein als das Fenster der Schlüssel-Überlappung. Der Cache darf veraltet sein; er darf nur niemals länger veraltet sein als das Fenster, in dem beide Schlüssel gültig sind. Genau diese eine Ungleichung ist es, die ein aggressiv gecachtes JWKS sicher macht.

Zusammengenommen wird die Rotation zu einer Überblendung mit fester Ablaufreihenfolge: neuen Schlüssel hinzufügen, eine TTL lang warten, bis der Edge und jeder Validator ihn sehen, mit dem Signieren beginnen, warten, bis die alten Tokens auslaufen, dann den alten Schlüssel fallen lassen. Jeder Schritt ist gegen einen Cache abgesichert, der eine TTL hinterherhinkt, weil die TTL kleiner gewählt wurde als jedes Fenster, um das ein Cache hinterherhängen könnte.

Die Lehre, herausgezogen

Caching ist normalerweise eine Latenz-Entscheidung. Das Cachen öffentlicher Schlüssel ist eine Korrektheits-Entscheidung, denn was Sie da cachen, ist genau das, was entscheidet, welche Tokens echt sind. Sie können es absolut an den Edge legen – Sie sollten es sogar, weil es öffentlich und heiß ist –, aber erst, wenn die Rotation als geordnete Überlappung statt als Tausch ausgedrückt ist, und erst, wenn die Cache-TTL nachweisbar kürzer ist als diese Überlappung. Machen Sie das richtig, dann rühren die meistfrequentierten, am besten cachebaren Dokumente Ihres Auth-Systems Ihren Origin nicht mehr an, und niemand bemerkt jemals den Unterschied – was genau der Sinn der Sache ist.