Depurar JWT sin filtrar secretos

La depuración de JWT suele empezar con alguien pegando un token en el chat. Eso resuelve el misterio inmediato y crea un candidato a incidente. Los bearer tokens son credenciales. Si entran en Slack, tickets, capturas, buscadores de logs, historial del navegador o un decoder de terceros, pueden quedar accesibles mucho después de arreglar el bug. Depurar de forma segura es un hábito, no una preferencia de herramienta.

Redactar antes de compartir

La mayoría de preguntas sobre JWT se responden con encabezado y payload, no con la firma, y a menudo ni siquiera con todos los valores. Sustituye sub, email, ids de sesión y tenant por placeholders estables. Conserva timestamps, emisor, audiencia, algoritmo y kid porque esos campos suelen importar. Si hay que probar la firma, usa un token de staging o una reproducción local, no una credencial viva de usuario.

Un formato útil conserva estructura:

{"iss":"https://issuer.example","sub":"user_123_redacted","aud":"api","exp":1770000000}

Eso basta para revisar vida, audiencia y forma de claims. No basta para que un atacante repita la request.

Logs que ayudan sin dañar

Los logs de aplicación deberían registrar resultado de verificación, emisor, audiencia, kid, algoritmo, edad del token y motivo del fallo. No deberían registrar el encabezado Authorization crudo. Si necesitas correlación, hashea el token o jti con una sal del servidor y registra el hash. Así puedes encontrar reutilización sin convertir la plataforma de logs en almacén de credenciales.

Hábitos de tooling

Prefiere herramientas locales de decodificación que no envían datos a la red. Los decoders web sirven para ejemplos públicos, no para tokens de producción. El historial de shell es otra fuga: comandos como jwt decode eyJ... pueden persistir en archivos de historial. Usa archivos con permisos restringidos o herramientas que no guarden historial. Limpia gestores de portapapeles al manejar tokens sensibles.

Soporte y canales de incidente

Los equipos de soporte necesitan guiones para pedir tokens redactados a clientes. Seguridad necesita una frase estándar para salas de incidente: no bearer tokens crudos, no capturas con encabezados, no reenviar HAR sin limpiar. Los HAR son especialmente peligrosos porque contienen cookies, encabezados Authorization, URLs y cuerpos de respuesta en un solo paquete cómodo.

Flujo práctico

Al depurar, reproduce primero con una cuenta de prueba. Captura el error del verificador y metadatos del token. Si hace falta evidencia de producción, extrae solo los campos mínimos con un scrubber aprobado. Guarda artefactos crudos, si son inevitables, en el vault de incidente con expiración y control de acceso. La disciplina parece lenta hasta que un token copiado se convierte en el segundo problema.