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).
Ein JWT besteht aus drei durch Punkte getrennten Teilen: header.payload.signature. Header und Payload sind Base64URL-kodiert; dieses Werkzeug dekodiert sie in lesbares JSON.
Füge ein JWT-Token ein (drei durch Punkte getrennte Teile), um den Header, den dekodierten Payload und die Metadaten (Ablauf, iat usw.) zu sehen.
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.
Im Tab Verifizieren prüfst du die Signatur wirklich (HS/RS/ES/PS), indem du das Geheimnis (HMAC) oder den öffentlichen Schlüssel (PEM oder JWK) angibst. alg:none wird abgelehnt und auf Algorithmus-Verwechslung hingewiesen. Alles geschieht in deinem Browser: Der Schlüssel verlässt niemals dein Gerät.
Unter Erstellen baust du ein JWT aus Feldern zusammen und signierst es (HMAC-Geheimnis oder ein Schlüsselpaar, das du generieren kannst). Unter Authz testen definierst du Gateway-Regeln (Issuer, Audience, Scopes/Rollen) und siehst, ob das Token ALLOW oder DENY ergäbe.
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.
Die Signatur garantiert, dass der Token nicht manipuliert wurde, aber der Inhalt wird nicht verschlüsselt: Jeder kann den Payload lesen. Nimm niemals sensible Daten ohne zusätzliche Verschlüsselung (JWE) auf.