JWT-verifier

De verifier controleert de handtekening met de sleutel die u opgeeft en vergelijkt daarna de exp-claim en de nbf-claim met de huidige tijd. Het oordeel is alleen geldig als de handtekening overeenkomt en geen van beide tijdcontroles mislukt. Claims zoals iss, aud of sub worden in de payload weergegeven, maar niet vergeleken met verwachte waarden.

Plak voor HS256, HS384 en HS512 het gedeelde geheim als tekst of als een oct JWK. Plak voor RSA-, EC- en EdDSA-tokens een openbare PEM-sleutel (SPKI of PKCS #1), een X.509 certificaat, een openbare of persoonlijke JWK, een JWKS met maximaal 50 sleutels of een persoonlijke PEM-sleutel, waarvan alleen het openbare deel wordt gebruikt.

Als de tokenheader een kid bevat, wordt de sleutel met dezelfde kid in de set gebruikt. Als er geen overeenkomt, vermeldt een foutmelding de kid. Zonder kid moet de set precies één sleutel bevatten. Dit komt overeen met de manier waarop de meeste servers sleutels selecteren uit een jwks_uri-document.

Met Use the token's alg wordt het algoritme uit de tokenheader gehaald, maar de sleutel moet er nog steeds bij passen. Een openbare RSA-sleutel kan dus nooit als HMAC-geheim worden gebruikt. Kies een specifiek algoritme om ook te vereisen dat de token dit gebruikt; zo legt een server het verwachte algoritme vast. Een token met een ander alg wordt dan afgewezen, waarbij beide namen worden getoond.

Een token met alg none heeft geen handtekening, dus er is niets te verifiëren en iedereen had de token kunnen maken. Het accepteren van zulke tokens is een bekende kwetsbaarheid in JWT-bibliotheken. De verifier meldt dit als een fout in plaats van een geldig resultaat.

Een token geldt als verlopen wanneer exp gelijk is aan of vóór de huidige tijd ligt, en als nog niet geldig wanneer nbf later valt dan de huidige tijd. De kloktolerantie, van 0 tot 3600 seconden, verruimt beide controles om klokafwijkingen tussen servers op te vangen. Claims die aanwezig zijn maar geen getal bevatten, maken de token ongeldig.

De token is niet ondertekend met de sleutel die u hebt opgegeven, of de header of payload is na het ondertekenen gewijzigd. Controleer of u de bijbehorende openbare sleutel of het geheim hebt geplakt, met exact dezelfde tekens, en of de token volledig is gekopieerd. De gedecodeerde header en payload worden nog steeds weergegeven, zodat u ze kunt vergelijken.

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 en EdDSA met Ed25519-sleutels. RSA-sleutels moeten minstens 2048 bits bevatten. Versleutelde tokens (JWE) worden niet ontsleuteld.

Nee. De token en sleutel worden alleen voor deze verificatie in het geheugen gebruikt en worden nooit gelogd of opgeslagen. Een openbare sleutel kunt u veilig delen, maar ga voorzichtig om met HMAC-geheimen en vervang elk geheim waarvan u vermoedt dat het is gelekt.

Tokens mogen maximaal 65,536 tekens bevatten en het sleutelveld maximaal 262,144 tekens; dat is genoeg voor grote JWKS-documenten. De token moet drie base64url-delen bevatten, gescheiden door punten, een JSON-header met een alg-lid en een JSON-object als payload.