Decodifique el payload JWT sin verificar la firma

Devuelve ambas secciones como objetos estructurados para que usted pueda examinar con facilidad claims, identificadores, marcas de tiempo, emisores, destinatarios y metadatos del algoritmo, o enviarlos a otra herramienta. La firma no se verifica deliberadamente: los valores decodificados indican lo que afirma el token, pero no demuestran quién lo creó. Utilice el resultado para depuración, desarrollo, documentación e inspección prudente, nunca como prueba de que un token es auténtico o está autorizado.

Comprenda qué demuestra la decodificación y qué no

Un JWT suele contener una cabecera, un payload y una firma, unidos por puntos. Los dos primeros segmentos son JSON codificado en base64url: su contenido está preparado para un transporte compacto, pero no está cifrado ni oculto. Esta capacidad divide el token proporcionado, decodifica esos dos segmentos como UTF-8, analiza su JSON y devuelve los objetos de cabecera y payload resultantes. No utiliza el tercer segmento para autenticar nada. Esta diferencia es fundamental, porque cualquiera puede construir una cadena con forma de token y claims arbitrarios. Ver un sujeto, rol, emisor, destinatario o valor de caducidad en el payload decodificado no prueba que un sistema de confianza lo haya emitido. Use la decodificación cuando necesite conocer la estructura del token, diagnosticar nombres o valores de claims u obtener una representación legible durante el desarrollo. Siempre que una decisión de seguridad dependa del token, use una biblioteca de verificación JWT adecuada con una clave expresamente confiable y restricciones de algoritmo, emisor y destinatario.

Envíe un JWT compacto e interprete la respuesta

Pegue o envíe el JWT compacto completo en el campo token. Un token estructuralmente válido tiene exactamente tres segmentos separados por dos puntos, aunque este decodificador solo lea los dos primeros. La respuesta contiene un objeto header y un objeto payload. Entre los campos habituales de la cabecera están typ, que suele identificar el tipo de medio JWT, y alg, que indica el supuesto algoritmo de firma. El payload suele incluir sub para el sujeto, iss para el emisor, aud para el destinatario, exp para la caducidad y claims propios de la aplicación. El decodificador no exige ningún claim: conserva los valores JSON presentes. Los claims NumericDate como exp, nbf e iat siguen siendo números y no se convierten en fechas, lo que evita imponer cómo debe mostrarlos o compararlos quien llama. Si el token tiene un número incorrecto de segmentos, base64url defectuoso, UTF-8 o JSON no válidos, o una sección decodificada que no es un objeto, la solicitud devuelve un error de entrada no válida en vez de un resultado parcial.

Utilice los claims decodificados con seguridad

La decodificación resulta especialmente útil en la frontera entre sistemas. Un desarrollador de API puede comparar los claims emitidos por un proveedor de identidad con los nombres que espera una aplicación. Un especialista de soporte puede examinar un token de prueba censurado para descubrir si falta un destinatario o un alcance. Un conjunto de pruebas puede decodificar tokens creados por una fixture local y comprobar que se incluyeron los claims personalizados necesarios antes de probar por separado la verificación criptográfica. Mantenga explícito el límite de seguridad en todo flujo: los datos decodificados son entrada no confiable. No conceda acceso, seleccione un tenant, acepte una identidad ni exponga información privada únicamente porque lo solicite un claim decodificado. Evite pegar tokens bearer reales en registros, incidencias, chats o documentos compartidos, pues un JWT puede ser una credencial activa aunque su payload parezca inofensivo. Para diagnosticar, prefiera ejemplos sintéticos, caducados o generados localmente. Si una automatización debe procesar tokens reales, envíelos solo por un canal debidamente protegido y, tras decodificarlos, verifíquelos con una configuración confiable.