Un token web JSON parece una pared de caracteres aleatorios, pero son solo tres piezas de JSON codificado. Esta guía explica qué contiene cada pieza, cómo leer las afirmaciones estándar y la diferencia crucial entre decodificar un token (seguro, lo que hace esta herramienta) y verificarlo (necesita un secreto, lo que hace un servidor).
Las tres partes de una ficha
Divida un JWT en sus puntos y obtendrá encabezado.carga útil.firma. El encabezado es un pequeño objeto JSON que describe cómo se firmó el token: su alg (algoritmo) y typ (tipo). La carga útil es la parte interesante: un objeto JSON de claims que describe de quién es el token y por cuánto tiempo es válido. La signature es una suma de verificación criptográfica sobre las dos primeras partes.
El encabezado y la carga útil solo están codificados, no cifrados. Cualquiera puede revertir Base64url, razón por la cual un decodificador como este puede mostrarle el contenido sin ninguna contraseña.
Standard claims you'll see most
La especificación JWT reserva un puñado de nombres de reclamos cortos. iss es el emisor, sub el sujeto (normalmente una identificación de usuario) y aud el público objetivo. Tres son marcas de tiempo: iat (emitida en), exp (vence) y nbf (no antes). Se almacenan como segundos desde 1970, por lo que un token sin formato muestra un número grande como 1717000000 en lugar de una fecha; esta herramienta los convierte por usted y le indica si la ventana aún está abierta.
Todo lo demás es un reclamo personalizado: roles, alcances, identificaciones de inquilinos, banderas de características. Son perfectamente válidos; simplemente no están definidos por el estándar, por lo que la Tabla de reclamaciones los marca como personalizado.
Signed is not encrypted
Un JWT normal (un JWS) está firmado. La firma significa que un servidor puede detectar si alguien alteró el encabezado o la carga útil, pero no hace nada para ocultarlos. Trate la carga útil como pública: nunca incluya contraseñas, números de tarjetas ni secretos en ella. Si el contenido en sí debe ser secreto, necesita un token cifrado (un JWE), que tiene cinco segmentos y no se puede leer sin la clave de descifrado.
Why decoding is safe but verifying isn't
Leer un token no necesita nada más que el token, por lo que hacerlo en su navegador es privado e inofensivo. Verificar es un trabajo diferente: demuestra que el token es auténtico y no ha caducado, y requiere el secreto HMAC del emisor (para HS256) o la clave pública (para RS256/ES256). Un navegador no puede almacenarlos de forma segura y un servidor nunca debe confiar en un token que no haya verificado por sí mismo. Es por eso que esta herramienta se detiene deliberadamente en la decodificación, y por qué nunca debes pegar un token de producción activo que no controlas, ya que quien tenga un token válido generalmente puede actuar como tú.