web-token implementiert JWS, JWE, JWK und JWK-Sets als separate Komponenten; web-token/jwt-library bündelt sie, und ein Symfony-Bundle bindet sie als Services ein. Für PHP ist es die richtige Wahl, wenn du JWE, die Verwaltung von JWK-Sets oder die vollständige Liste der Algorithmen brauchst: Version 4.2.3 signierte und prüfte HS, RS, PS und ES bei 256/384/512 sowie EdDSA, einschließlich PS384/512 und ES512, die es in firebase/php-jwt nicht gibt. Eine Algorithmusklasse für ES256K oder für das vollständig spezifizierte Ed25519 gibt es nicht.
Algorithmen werden ausdrücklich zugelassen: Der AlgorithmManager, den du an JWSVerifier übergibst, ist die Allowlist, und ein Token mit einem anderen Algorithmus scheitert mit The algorithm "RS256" is not supported. none existiert als Algorithmusklasse, wird aber nur akzeptiert, wenn du es in den Manager aufnimmst. Ein mit dem PEM-Text des EC-Schlüssels gefälschtes HS256-Token scheiterte selbst bei zugelassenem HS256, weil sich ein EC-JWK nicht als HMAC-Schlüssel verwenden lässt. ES256 mit einem P-384-Schlüssel erzeugte eine Signatur, die der Verifizierer der Bibliothek selbst ablehnte.
Signaturprüfung und Prüfung der Claims sind getrennte Schritte: JWSVerifier::verifyWithKey() gab true für ein Token zurück, das eine Stunde zuvor abgelaufen war. Führe danach einen ClaimCheckerManager aus, liste die Pflicht-Claims auf – sonst ist exp keine Pflicht – und übergib ExpirationTimeChecker eine Toleranz (Drift); seit Version 4 braucht er außerdem eine Uhr nach PSR-20. Das Beispiel zeigt den gesamten Ablauf.
ES256-Signaturen bestehen aus 64 Byte rohem r‖s, und bei einer DER-Signatur gibt verifyWithKey() false zurück; der JWT-Debugger zeigt, welche Form ein Token enthält. Schlüssel sind durchgehend JWK-Objekte; JWKFactory erzeugt sie aus PEM, Zertifikaten oder Schlüsselparametern, und der JWKS-Builder erstellt Schlüsselsätze im selben Format.