Decodificar tokens JWT y JWS en el navegador

Entender las tres partes

Un JWT firmado suele tener tres partes separadas por puntos: cabecera Base64URL, contenido Base64URL y firma. JWS describe el contenedor firmado. Las dos primeras partes están codificadas, no cifradas: quien posee el token normalmente puede leerlas. Los tokens cifrados pueden usar otro formato que este decodificador no admite.

Inspeccionar un token

Abra el decodificador JWT, pegue un token de ejemplo y revise los objetos JSON. El procesamiento principal ocurre en el navegador. Una parte Base64URL inválida o un JSON incorrecto indican un error de entrada; no demuestran un ataque. Introduzca solamente el token, sin la cabecera HTTP Authorization.

{ "alg": "HS256", "typ": "JWT" }

Interpretar los campos

El campo alg indica el algoritmo declarado. iss identifica al emisor y aud a la audiencia; exp, nbf e iat son marcas Unix en segundos. Puede consultar las fechas con el conversor de tiempo. Valide estos campos en el servidor con claves de confianza y algoritmos permitidos explícitamente. No autorice solicitudes basándose solamente en datos decodificados.

Proteger los datos sensibles

El decodificador principal trabaja localmente. La asistencia de IA opcional es una acción independiente que puede enviar datos al proveedor externo tras su consentimiento. Evite usar credenciales reales. La carga del sitio solicita recursos por la red; el uso sin conexión requiere que las páginas necesarias estén guardadas en caché. Borrar la entrada no garantiza la eliminación segura de la memoria.

Errores de Validación Arquitectónica (RFC 7519)

Al depurar tokens JWT en arquitecturas de producción, inspeccionar el contenido es solo el primer paso de diagnóstico. Los desarrolladores deben verificar tres límites de seguridad críticos antes de confiar en los datos:

1. La vulnerabilidad del algoritmo “none”: Las bibliotecas mal configuradas pueden aceptar tokens donde "alg": "none" elude la comprobación de firma. Aplique siempre una lista blanca estricta de algoritmos (como RS256 o ES256) en su middleware de autenticación.
2. Ataques de confusión de claves (HMAC frente a RSA): Si un backend espera una clave pública RSA pero utiliza una rutina de verificación genérica, un atacante puede intentar firmar un token manipulado con HMAC-SHA256 usando la clave pública como secreto. Nunca permita que el encabezado del token dicte la familia criptográfica dinámicamente.
3. Desviación de reloj y tolerancia de red: Las comprobaciones de expiración (exp) suelen fallar por pequeñas discrepancias de tiempo entre servidores. Configure un margen de tolerancia (de 30 a 60 segundos) para compensar el desfase NTP y la latencia de red.