DAT (Distributed Access Token) ​

Hintergrund der Einführung von DAT ​

Heute setzen viele Systeme auf JWT, doch im realen Produktionsbetrieb bestehen die folgenden strukturellen Grenzen.
Um diese zu überwinden, wurde die neue Token-Spezifikation DAT entworfen.

🧩 Fragmentierung der Sicherheitsspezifikation und fehlende Durchsetzung ​

JWT bietet zwar Verschlüsselungsstandards wie JWE an, deren Verwendung wird jedoch nicht erzwungen.
Dadurch verzichten viele Entwicklungsumgebungen auf die Verschlüsselung oder übertragen Daten auf nicht standardisierte Weise, was Sicherheitslücken verursacht.

🔑 Sicherheitsrisiko durch statische Schlüssel (Static Key) ​

Da die Rotation von Signaturschlüsseln (Key-Rolling) nicht verpflichtend ist, wird ein einzelner Schlüssel häufig über lange Zeiträume verwendet. Bei einer Kompromittierung des Schlüssels kann dies zum Zusammenbruch der Sicherheit des gesamten Systems führen; tatsächlich sind auf großen Commerce-Sites bereits Sicherheitsvorfälle dieser Art aufgetreten.

📉 Leistungseinbußen durch Overhead ​

JWT durchläuft bei jeder Anfrage einen JSON-Parsing-Vorgang und verbraucht dabei erhebliche CPU-Ressourcen. In Umgebungen mit hohen Leistungsanforderungen können diese Parsing-Kosten zum Engpass des gesamten Systems werden.

Kernphilosophie von DAT ​

DAT wurde nach dem Grundsatz entworfen, dass Sicherheit nicht optional, sondern erzwungen sein muss und dass bei der Leistung keine Kompromisse eingegangen werden dürfen.

⚡ Leicht und schnell ​

Wie oben dargestellt, besitzt DAT genau fünf feste, durch Punkte (.) getrennte Felder. Da die Position jedes Feldes durch die Spezifikation festgelegt ist, lassen sich die einzelnen Werte ohne JSON-Parsing allein anhand der Trennzeichen herausschneiden.

🔐 Erzwungene Sicherheit ​

DAT trennt bei der Datenübertragung den Klartextbereich (Plain) und den verschlüsselten Bereich (Secure) physisch voneinander.
Sensible Informationen müssen zwingend verschlüsselt werden, und der gesamte Vorgang wird durch die im Zertifikat deklarierten Standardalgorithmen (ECDSA, AES-GCM usw.) geschützt.

Über den Verschlüsselungsalgorithmus entscheidet das Zertifikat, nicht das Token. Da das Token keinerlei Algorithmusinformationen enthält, existiert die Angriffsfläche für Algorithmusverwechslungsangriffe, wie sie der alg-Header von JWT eröffnet, hier gar nicht.

🔄 Erzwungenes Key-Rolling ​

DAT-Zertifikate verwalten nicht nur Ausstellung und Ablauf von Tokens, sondern unmittelbar auch den Lebenszyklus der Schlüssel.
Im Zertifikat ist auf Spezifikationsebene festgeschrieben, „von wann bis wann ausgestellt werden darf". Nach Ablauf dieses Zeitraums lassen sich mit dem Zertifikat keine neuen Tokens mehr erzeugen. Die Situation, dass aus Unachtsamkeit des Administrators ein einzelner Schlüssel jahrelang verwendet wird, kann strukturell nicht eintreten.

⏱️ Trennung von Ausstellungsfenster und Gültigkeitsdauer ​

„Der Zeitraum, in dem ein Zertifikat Tokens ausstellen darf" und „der Zeitraum, in dem ein ausgestelltes Token gültig bleibt" sind zwei verschiedene Werte.
Dadurch können bereits ausgegebene Tokens ihre volle Lebensdauer ausschöpfen, auch nachdem das Zertifikat die Ausstellung eingestellt hat, während der Cluster in der Zwischenzeit reibungslos auf das nächste Zertifikat übergeht.

Vergleich der Authentifizierungsmechanismen ​

Performance ​

Weiterführende Dokumente ​

• DAT — Wire-Format des Tokens und kanonische Regeln
• Zertifikat — Zertifikatsstruktur, Algorithmen, Lebenszyklus
• CMS-Synchronisierung — Zertifikatsverteilung und im Betrieb zu beachtendes Verhalten