Mit steigender Anzahl gleichzeitiger Benutzer wächst auch die Anzahl der Sitzungen (Sessions), was zu einer übermäßigen Last auf dem Sitzungsserver führt.
DAT ist eine Token-Spezifikation, die entwickelt wurde, um die Lastprobleme solcher Sitzungsserver zu lösen und eine effiziente, zustandslose (Stateless) Authentifizierung ohne gemeinsamen Zustand zwischen Servern zu ermöglichen.
Ablaufzeit : uint64 (Unix Time)
CID : Hex (uint64)
Klartextdaten : Base64Url (Binary)
Verschlüsselte Daten : Base64Url (Binary)
Signatur : Base64Url (Binary)
DAT und JWT (JSON Web Token) teilen eine durch Punkte (.) getrennte Token-Struktur sowie eine Validierung mittels signature, unterscheiden sich jedoch im internen Design in den folgenden wesentlichen Punkten.
JWT-Struktur
| header | body | signature |
|---|---|---|
| Base64Url (JSON String) | Base64Url (JSON String) | Base64Url (Binary) |
DAT-Struktur
| Ablaufzeit | CID | Klartextdaten | Verschlüsselte Daten | Signatur |
|---|---|---|---|---|
| Unixtime (uint64) | Hex (uint64) | Base64Url (Binary) | Base64Url (Encrypt Binary) | Base64Url (Binary) |
Verschlüsselte Daten (secure)): Bei JWT ist der Payload standardmäßig im Klartext sichtbar; soll er verschlüsselt werden, muss eine separate Spezifikation wie JWE angewendet werden. DAT hingegen unterstützt Verschlüsselung nativ über das Feld Verschlüsselte Daten direkt im Token.exp (Claims) optional, während in DAT das Feld Ablaufzeit (expire) strukturell verpflichtend ist, sodass die Gültigkeitsprüfung zwingend durchgeführt wird.