Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Ein JSON Web Token ist ein kompaktes, signiertes Token, das eine kleine Menge von Claims trägt, typischerweise wer der Nutzer ist und was er tun darf. Es hat drei Teile: einen Header, eine Payload mit Claims und eine Signatur. Der Server signiert es mit einem Secret oder einem privaten Schlüssel, übergibt es dem Client nach dem Login, und der Client sendet es mit jeder Anfrage zurück. Der Server prüft die Signatur und vertraut dem Inhalt, ohne etwas nachzuschlagen.
Dieser letzte Punkt ist der ganze Reiz. Eine klassische Session speichert Zustand auf dem Server und fragt bei jeder Anfrage die Datenbank ab. Ein JWT ist eigenständig, sodass jeder Server mit dem Verifizierungsschlüssel es validieren kann, was zu APIs und verteilten Systemen passt, in denen es keinen gemeinsamen Session-Speicher gibt. Die Payload ist signiert, nicht verschlüsselt, also für jeden lesbar, der das Token hält, was bedeutet, dass niemals Secrets hineingehören. Der schwierige Teil ist der Widerruf: Weil das Token bis zum Ablauf gültig ist, können Sie nicht einfach eine Session löschen, um jemanden abzumelden. Nach der Anmeldung an einer API erhält ein Client ein JWT und hängt es an jeden weiteren Aufruf, und der Server liest die Identität des Nutzers direkt aus dem verifizierten Token.
JWTs kombinieren meist kurzlebige Access Tokens mit länger lebenden Refresh Tokens, um Komfort gegen das Widerrufsproblem auszubalancieren.
Wir nutzen JWTs, wo sie passen, nämlich bei zustandsloser API-Authentifizierung über Dienste hinweg, und wir sind bewusst darin, wo sie nicht passen. Kurze Ablaufzeit bei Access Tokens, sorgfältig gehandhabte Refresh Tokens und niemals sensible Daten in einer Payload, die jeder dekodieren kann. Die Widerrufslücke ist real, also gestalten wir für sie, statt sie an dem Tag zu entdecken, an dem ein Kunde ein kompromittiertes Konto zwangsweise abmelden muss.
Authentifizierung ist einer dieser Bereiche, in denen ein kleiner Fehler zum Sicherheitsvorfall wird, also behandeln wir sie als Kern-Engineering, nicht als Bibliothek, die man einmal verdrahtet. Token-Speicherung, Ablauf, Refresh-Flows und Signaturprüfung erhalten dieselbe Sorgfalt wie der Rest unserer individuellen Web-App-Entwicklung und unserer API-First-Entwicklung. Das Ziel ist eine Authentifizierung, die unsichtbar ist, wenn sie funktioniert, und unmöglich zu umgehen, wenn jemand es versucht.
Bauen Sie Authentifizierung in eine API und wollen sie richtig gemacht? Machen wir die Token-Strategie solide.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















