Herramientas de desarrollo · JWT decodificador
El encabezado JWT explicado: alg, typ, kid y los campos para desconfiar
· Cómo funciona
jwt seguridad autenticación
El encabezado le dice al verificador cómo se firmó el token y qué clave usar. Esta publicación explica cada campo de encabezado común, en qué puede confiar un verificador y en qué campos nunca se debe confiar desde el token en sí.
El pequeño objeto JSON que nadie lee y las decisiones de verificación en las que influye
El encabezado es lo suficientemente pequeño como para pasarlo por alto, pero sus campos a menudo participan en el enrutamiento de verificación. Eso hace que sea peligroso confundir visibilidad con autoridad. ToolAcre decodifica el encabezado como un objeto JSON y muestra sus propiedades, pero cada byte proviene del titular del token y sigue siendo una entrada que no es de confianza.
Un verificador puede usar un valor de encabezado solo dentro de las restricciones establecidas a partir de una configuración confiable. No debe permitir que el token invente un algoritmo, emisor o fuente de clave remota aceptados. El trabajo del descodificador finaliza en JSON legible más advertencias; nunca elige una clave ni produce una decisión de permitir o denegar.
visualización de alg: el decodificador explica solo los algoritmos nombrados en su implementación
`alg` declara el algoritmo que el token afirma que se utilizó. ToolAcre tiene notas explicativas para HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 y PS512, además de una advertencia para `none`. Cualquier otra cadena se muestra como no reconocida en lugar de tratarse como compatible.
Esta lista es una función de visualización, no un catálogo de algoritmos que ToolAcre puede verificar: no verifica ninguno de ellos. Un backend debe fijar sus opciones permitidas de forma independiente y rechazar una discrepancia. Leer `alg: RS256` no puede probar que se utilizó RSA, del mismo modo que leer `alg: none` no puede autorizar de forma segura un token sin firmar.
typ y cty: declara el tipo de token, el perfil at+jwt para tokens de acceso y JWT anidados
`typ` describe el tipo de medio o perfil que pretende el productor. ToolAcre advierte cuando un valor de cadena difiere de `JWT`; no impone la semántica del perfil. Un campo `cty` puede describir contenido anidado, pero el descodificador actual no tiene una ruta de procesamiento de token anidado y no interpreta ese campo.
La escritura explícita puede ayudar a un verificador a mantener separadas las diferentes clases de tokens cuando su política define los valores esperados. El cheque todavía pertenece a ese verificador. Un token no puede convertirse en un token de acceso simplemente anunciando una etiqueta preferida, y un panel de decodificación no puede determinar qué punto final de la aplicación debe consumirlo.
kid: el identificador de clave que permite a los verificadores rotar claves sin tiempo de inactividad
`kid` es un identificador de clave, no material de clave ni prueba de propiedad. Un servicio que rota varias claves confiables puede utilizar un contexto de emisor autenticado y un identificador restringido para localizar a un candidato. El identificador debe permanecer como entrada para una búsqueda controlada en lugar de una ruta de archivo, un fragmento de consulta o una URL arbitraria.
ToolAcre deja `kid` visible en el encabezado JSON pero no lo resuelve. Esa restricción es importante: no hay ningún almacén de claves confiable disponible para una página de decodificación pública. Si un 401 sigue la rotación, compare el identificador mostrado con el inventario de claves y los registros del lado del servidor sin asumir que la clave sugerida del token es legítima.
jku, x5u, jwk y x5c: campos de encabezado que apuntan a claves y por qué un verificador nunca debe buscarlas ni confiar en ellas ciegamente
Campos como `jku` y `x5u` pueden nombrar ubicaciones, mientras que `jwk` y `x5c` pueden contener datos relacionados con claves. Su presencia no hace que esos lugares o valores sean confiables. Obtener una URL o aceptar material incrustado únicamente porque se proporcionó un encabezado no verificado le otorga una decisión de seguridad al solicitante.
Un verificador seguro obtiene claves a través de una relación con el emisor y una política de red establecida fuera del token. ToolAcre no recupera las URL de encabezado ni genera confianza a partir de claves integradas. Durante la revisión, ver uno de estos campos es un mensaje para inspeccionar la configuración del verificador, no una instrucción para seguir el encabezado.
crit: extensiones que un verificador debe comprender o rechazar
`crit` indica que extensiones particulares requieren comprensión por parte del destinatario. Un verificador que admita dicha extensión necesita una implementación explícita y una ruta de rechazo para nombres críticos desconocidos. Ignorar un marcador crítico desconocido puede hacer que el productor y el consumidor interpreten el contenido protegido de manera diferente.
La implementación de solo decodificación no procesa `crit`, por lo que puede mostrar la matriz sin formato sin reclamar compatibilidad. Este es otro límite entre la inspección y la validación. Si un token de producción depende de extensiones críticas, verifique el comportamiento en la biblioteca y la configuración reales en lugar de inferir soporte de JSON legible.
Ejemplo resuelto: leer un encabezado realista y decidir qué campos informan la verificación y cuáles son meramente informativos
Considere `{"alg":"RS256","typ":"JWT","kid":"rotate-7"}`. ToolAcre imprime los tres campos y explica que la verificación RS256 necesita una clave pública del emisor. Un revisor puede anotar el algoritmo declarado y el identificador de clave, luego compararlos con la política fijada del servidor y el conjunto de claves confiables.
Los campos informan la investigación pero no deciden nada de forma independiente. Si el servidor solo permite otro algoritmo, no puede encontrar `rotate-7` en el conjunto de emisores correcto o rechaza la firma, el encabezado legible no anula ese resultado. Del mismo modo, no se debe aceptar cambiar el texto del encabezado sin volver a calcular una firma válida.
Conclusión: el encabezado es entrada, no autoridad: el decodificador ToolAcre JWT muestra el encabezado para que pueda leerlo; el verificador debe decidir independientemente en qué confiar
Trate el encabezado JWT como entrada, no como autoridad. Sus valores pueden ayudar a seleccionar entre opciones ya autorizadas por la configuración, identificar un posible problema de rotación o explicar una discrepancia en el perfil. No pueden generar confianza en su propio algoritmo, clave, URL o tipo de token.
Utilice ToolAcre para leer un encabezado de prueba y mostrar valores sospechosos, como `alg`, `none` faltantes o un `typ` inesperado. Luego pase al verificador configurado para cada decisión importante. La decodificación no demuestra autenticidad, integridad, autorización o identidad del emisor, independientemente de cuán plausible parezca el encabezado.