Herramientas de desarrollo · JWT decodificador
Decodificar versus verificar: lo que demuestra una firma JWT y por qué los decodificadores la omiten
· Cómo funciona
jwt seguridad criptografía
La decodificación no necesita clave; verificar necesita el correcto. Esta publicación explica qué cubre la firma, en qué se diferencian HMAC y la verificación asimétrica, y por qué una herramienta de solo decodificación es honesta al no demostrar nada.
Se decodificó bien, por lo que debe ser válido: la suposición que lleva a aceptar tokens falsificados
Un token se puede decodificar perfectamente después de que un atacante escribe una nueva carga útil y adjunta texto arbitrario como tercer segmento. El análisis de Base64url y JSON son transformaciones públicas; ninguno comprueba quién ensambló la cuerda. Por lo tanto, “las reclamaciones aparecieron en la pantalla” no es prueba de que el emisor las haya creado o aprobado.
ToolAcre refuerza este límite en varios lugares. El resultado siempre lleva `signatureVerified: false`, la interfaz de usuario repite una alerta de reclamos no verificados junto al resultado y las pruebas afirman que no hay ninguna superficie `valid` o `verify`. Esto es honestidad deliberada, no una característica de conveniencia que falta.
Lo que cubre la firma: los bytes exactos del encabezado codificado y la carga útil, unidos por un punto
Para JWS compacto, la entrada de firma es el segmento de encabezado protegido codificado, un punto literal y el segmento de carga útil codificado. La verificación se refiere a esos bytes codificados exactos, no a los JSON recién impresos. Reordenar las propiedades o cambiar los espacios en blanco puede crear bytes diferentes incluso cuando un humano ve objetos equivalentes.
El tercer segmento lleva la firma codificada o los bytes MAC producidos a través de esa entrada. ToolAcre conserva el segmento sin formato y puede informar su longitud en bytes, pero nunca ejecuta una verificación criptográfica. La forma de los datos de medición no puede establecer que la clave esperada la creó o que los dos primeros segmentos permanecieron sin cambios.
HMAC versus asimétrico: un secreto compartido que cualquiera que pueda verificar también puede falsificar, versus una clave pública que solo puede verificar
Con HMAC, un secreto compartido permite crear y verificar la MAC. Una parte capaz de verificar ese secreto también puede acuñar otro token, por lo que la distribución del secreto define el límite de confianza. Las notas de ToolAcre hacen explícita esta consecuencia para sus reconocidas etiquetas de algoritmo HS.
Las firmas asimétricas separan una capacidad de firma privada del material de verificación pública. Poseer una clave pública puede permitir la verificación sin otorgar autoridad de firma. Esta distinción no hace que una etiqueta asimétrica declarada en el encabezado sea confiable: el verificador ya debe saber qué algoritmo y clave de emisor son aceptables.
De dónde proviene la clave: configuración para secretos compartidos, un punto final JWKS para claves públicas, coincidente por niño
Los secretos compartidos deben provenir de la configuración del servicio protegido, no del texto simbólico. Las claves de verificación públicas pueden provenir de una relación de emisor confiable y de un conjunto de claves controlado. Un `kid` puede ayudar a seleccionar dentro de ese conjunto, pero no debe convertir contenido de encabezado arbitrario que no sea de confianza en un archivo, base de datos o búsqueda de red.
ToolAcre no tiene configuración de emisor y no solicita ninguna clave, por lo que sería imposible realizar la verificación de manera responsable allí. Una página web genérica no puede inferir en qué organización confía, a qué audiencia atiende o qué algoritmos permite su aplicación. Esas son entradas de políticas de aplicación, no propiedades que se pueden descubrir mediante decodificación.
Por qué la decodificación no necesita clave: base64url es una codificación, no un cifrado, por lo que cualquiera puede leer las afirmaciones
No se necesita ninguna clave para decodificar porque base64url es una codificación reversible en lugar de cifrado. El encabezado y la carga útil deben viajar con el token y cualquier titular puede recuperarlos. Esto permite una inspección útil, pero también significa que la información confidencial no debe ocultarse detrás del ruido visual de los caracteres codificados.
JSON el análisis agrega estructura únicamente. Puede indicarle que `roles` es una matriz o `exp` es un número, pero no que ninguno de los valores sea auténtico. ToolAcre presenta valores estructurados como texto y descripciones registradas como documentación, al tiempo que deja autorización al sistema que puede verificar y hacer cumplir la política.
Ejemplo resuelto: un token con un carácter de carga útil cambiado todavía se decodifica perfectamente; solo avisos de verificación
Comience con un token sintético cuya carga útil dice `{"sub":"demo","role":"reader"}`. Cambie un carácter de carga útil codificado para que los bytes sigan formando un JSON válido, lo que quizás produzca una función diferente. Ambas versiones pueden dividirse, decodificarse y embellecerse. La ruta de decodificación no tiene ningún motivo para rechazar la versión modificada.
Un verificador configurado correctamente vuelve a calcular o verifica el resultado criptográfico sobre la entrada de firma modificada y rechaza la falta de coincidencia. Esta comparación demuestra el límite preciso: el éxito del decodificador cubre la sintaxis, mientras que el éxito del verificador puede establecer la integridad relativa a una clave confiable y un algoritmo permitido antes de que se evalúe la política de reclamo.
Lo que esto no cubre: el decodificador ToolAcre JWT nunca verifica la firma, por diseño; nada de lo que muestra demuestra que una ficha es genuina
ToolAcre nunca verifica la firma. Un segmento vacío recibe una advertencia, la codificación de firma con formato incorrecto recibe otra y los bytes medibles se informan como presentes pero no verificados. Ninguna de estas ramas produce un veredicto simbólico genuino. La implementación no tiene una adquisición de clave oculta ni una ruta de ejecución de algoritmo.
Incluso una verificación criptográfica exitosa no autorizaría automáticamente una acción. El servicio consumidor aún necesita verificaciones específicas del emisor, la audiencia, el tiempo y la aplicación. Este artículo termina antes de la configuración de la biblioteca porque el soporte y los valores predeterminados varían; consulte el verificador exacto y la versión utilizada por su servicio.
Conclusión: decodificar para inspeccionar, verificar para confiar: use el decodificador ToolAcre JWT para el primero y una biblioteca del lado del servidor con la clave correcta para el segundo
Decodificar para inspeccionar y verificar antes de confiar. Utilice la herramienta del navegador para un token sintético o caducado cuando necesite ver campos de encabezado, valores de carga útil, conversiones de tiempo y advertencias estructurales. Nunca permita que esa salida legible fluya directamente hacia una decisión de acceso.
Traslade el trabajo consiguiente a un verificador confiable con material clave, algoritmos fijados y política de servicio proporcionados de forma independiente. Sólo ese camino puede probar la autenticidad y la integridad, y sólo las comprobaciones de reclamaciones posteriores pueden decidir la autorización. La negativa de un decodificador a difuminar esos trabajos es una característica de seguridad.