Un JWT (JSON Web Token) es una credencial compacta y firmada que viaja como una cadena de texto. Se usa sobre todo como token de acceso en APIs, logins y OAuth 2.0 / OpenID Connect: el cliente lo manda en cada petición en la cabecera Authorization: Bearer … y el servidor comprueba la firma para saber quién eres y qué puedes hacer sin consultar una base de datos. La firma garantiza que nadie lo ha manipulado, pero no cifra su contenido: cualquiera puede leerlo (esta misma herramienta lo hace).

Un JWT se compose de trois parties séparées par des points : header.payload.signature. Le header et le payload sont encodés en Base64URL ; cet outil les décode en JSON lisible.

Collez un token JWT (trois parties séparées par des points) pour voir le header, le payload décodé et les métadonnées (expiration, iat, etc.).

El campo alg del header dice con qué algoritmo se firmó. Esta herramienta soporta 12, en tres familias; el número es el tamaño del hash SHA (256/384/512).

• HS256 / HS384 / HS512 (HMAC + SHA) — simétricos: la misma clave secreta firma y verifica. Sencillos y rápidos. Úsalos cuando quien firma y quien verifica son la misma parte o comparten el secreto de forma segura (p. ej. un backend que emite y consume sus propios tokens). Inconveniente: cualquiera que pueda verificar también puede falsificar.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — asimétricos: se firma con la clave privada y se verifica con la clave pública. Los más extendidos en OAuth/OIDC: el emisor guarda la privada y publica la pública (JWKS) para que cualquiera verifique sin poder falsificar. Claves grandes (2048 bits) y firma más lenta.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — RSA asimétrico como RS, pero con relleno PSS (probabilístico), considerado más robusto. Elígelo si tu plataforma lo admite y quieres el RSA moderno.
• ES256 / ES384 / ES512 (ECDSA + curvas P-256/P-384/P-521) — asimétricos de curva elíptica: mismas garantías que RSA pero con claves y firmas mucho más pequeñas y rápidas. Buena opción por defecto para tokens nuevos.

Regla práctica: HS* si compartes un secreto en un entorno controlado; ES* o RS*/PS* si terceros deben verificar sin poder emitir.

Dans l'onglet Vérifier, vous contrôlez réellement la signature (HS/RS/ES/PS) en fournissant le secret (HMAC) ou la clé publique (PEM ou JWK). alg:none est rejeté et la confusion d'algorithme est signalée. Tout se passe dans votre navigateur : la clé ne quitte jamais votre appareil.

Dans Créer vous construisez un JWT à partir de champs et le signez (secret HMAC ou paire de clés que vous pouvez générer). Dans Tester authz vous définissez les règles d'une gateway (issuer, audience, scopes/rôles) et voyez si le token donnerait ALLOW ou DENY.

Los claims son los campos del payload. Los registrados (RFC 7519) tienen significado estándar:

• iss — emisor: quién creó el token.
• sub — sujeto: a quién identifica (normalmente el usuario).
• aud — audiencia: para quién es; el receptor debe estar en ella.
• exp — expiración: instante tras el cual deja de valer.
• nbf — no antes de: no vale hasta ese instante.
• iat — emitido en: cuándo se creó.
• jti — ID único: útil para revocación o anti-replay.

Los tiempos van en segundos Unix (segundos desde 1970). La herramienta los muestra como fecha local y en relativo («hace 3 h», «dentro de 42 min») y marca en rojo si el token está caducado (exp pasado) o aún no vale (nbf futuro). Ojo: decodificar no valida — la caducidad solo obliga si el servidor la comprueba al verificar.

La pestaña Probar authz simula la decisión de un gateway o API: defines las reglas que exigirías (emisor, audiencia, scopes/roles) y la herramienta contrasta el token pegado y muestra ALLOW o DENY regla por regla, indicando qué falta o no coincide (incluidas exp y nbf). Sirve para entender por qué un token sería aceptado o rechazado sin montar el backend.

La signature garantit que le token n'a pas été altéré, mais elle ne chiffre pas le contenu : n'importe qui peut lire le payload. N'incluez jamais de données sensibles sans chiffrement supplémentaire (JWE).