JWT (JSON Web Token) besteht typischerweise aus einem Header + Payload + Signatur.
Header
Enthält die Metadateninformationen über das JWT.
alg: der zum Signieren des Tokens verwendete Algorithmus.
typ: der Typ des Tokens, immer JWT.
{
"alg": "HS256",
"typ": "JWT"
}Sie können weitere Header finden, aber die vorherigen werden immer vorhanden sein.
Payload
Die Payload enthält die Claims des JWT. Die Standard-Header sind die folgenden:
iss: der Issuer, die Entität, die das JWT generiert und ausstellt.
sub: das Subject, die durch dieses Token identifizierte Entität.
aud: die Audience, die Zielgruppe für dieses JWT.
exp: das Ablaufdatum, der Zeitstempel im UNIX-Format, nach dem das Token nicht mehr akzeptiert werden sollte.
iat: Ausgestellt-am, gibt das Datum an, an dem das Token ausgestellt wurde.
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Signatur
Die Signatur wird unter Verwendung des codierten Headers, des codierten Payloads, eines Secrets und eines kryptografischen Algorithmus erstellt.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Die folgenden Algorithmen werden sowohl von den Client- als auch von den Server-JWT-Komponenten unterstützt.
OpenSSL-Bibliotheken sind erforderlich, um das JWT zu signieren und zu verifizieren, mit einer Ausnahme.
Die drei ML-DSA-Algorithmen sind die Post-Quanten-JOSE-Algorithmen von RFC 9964, und sie sind die oben genannte Ausnahme: Sie sind in reinem Object Pascal im sgcCrypto-Pack implementiert, signieren und validieren also ohne vorhandene OpenSSL-Bibliothek. Die Signatur ist FIPS 204 ML-DSA im Pure-Modus mit leerem Kontext über den JWS-Signatureingang, im Token als base64url transportiert. Der Signierer ist deterministisch, derselbe Schlüssel und derselbe Eingang erzeugen also immer dieselbe Signatur.
Die Enum-Werte sind jwtMLDSA44, jwtMLDSA65 und jwtMLDSA87, und der alg-Header, den sie schreiben, lautet ML-DSA-44, ML-DSA-65 und ML-DSA-87. Der Client signiert mit JWTOptions.Algorithms.MLDSA.PrivateKey, einem privaten PKCS#8-PEM-Schlüssel, und der Server validiert mit JWTOptions.Algorithms.MLDSA.PublicKey, einem öffentlichen SubjectPublicKeyInfo-PEM-Schlüssel. Der Parametersatz des Schlüssels muss derjenige sein, den der Algorithmus benennt: Andernfalls löst das Signieren einen Fehler aus, und die Validierung gibt False zurück.
Signaturen sind groß. Eine ML-DSA-44-Signatur ist 2420 Byte groß gegenüber 64 Byte bei ES256, ein Token wächst also um rund 3,2 KB base64url, und ein ML-DSA-87-Token um etwa 6,2 KB. Prüfen Sie die Header-Größenbeschränkungen von allem, was das Token durchläuft, bevor Sie es einsetzen.
Schlüssel können auch als AKP JSON Web Keys transportiert werden, RFC 9964 Abschnitte 3 und 4. sgcMLDSA_ExportPublicJWK und sgcMLDSA_ExportPrivateJWK schreiben einen, sgcMLDSA_ImportJWK liest beide Formen, und sgcMLDSA_ImportJWKAsPEM wandelt einen JWK direkt in die PEM-Strings um, die die beiden Komponenten lesen. Ein privater JWK speichert den 32 Byte langen Seed in priv, der einzigen privaten Form, die Abschnitt 4 definiert, ein expandierter privater Schlüssel lässt sich also nicht als JWK schreiben. Alle vier Funktionen sind in sgcHTTP_JWT_MLDSA deklariert.
* Die ML-DSA-Algorithmen benötigen das sgcCrypto-Pack. Ohne es existieren die Enum-Werte weiterhin, ein damit gespeichertes Formular lädt also noch, aber das Signieren löst einen Fehler aus und jedes ML-DSA-Token wird abgelehnt.
TsgcHTTP_JWT_Client: JWT-Client, der Ihnen ermöglicht, JWT zu codieren und zu signieren und als Authorization- Header in den Protokollen HTTP und WebSocket zu senden.
TsgcHTTP_JWT_Server: JWT-Server, mit dem Sie JWT dekodieren und validieren können, das als Authorization-Header in den Protokollen HTTP und WebSocket empfangen wird.
* JWT-Komponenten erfordern mindestens Indy-Version 10.6.0.5169 oder sgcWebSockets Enterprise Edition.