Herramientas de desarrollo · Decodificador JWT
Anatomía de un JWT: división por puntos y decodificación de Base64url
· Cómo funciona
jwt codificación seguridad
Un JWT consta de tres segmentos de base64url separados por puntos. Esta publicación decodifica cada parte a mano, explica por qué el segmento de firma no es texto y muestra lo que un decodificador puede y no puede decirle.
La cadena larga en el encabezado Autorización: qué está viendo y por qué tiene exactamente dos puntos
Un token de portador suele llegar en un encabezado de Autorización como una cadena compacta separada por puntos. Un JWT típico firmado en forma JWS compacta tiene tres segmentos y, por lo tanto, dos puntos de separación. Un token activo es una credencial: no pegue tokens de producción en una demostración.
Serialización compacta: encabezado, carga útil y firma como tres segmentos base64url
En la serialización JWS compacta, el primer segmento es el encabezado protegido, el segundo es la carga útil y el tercero es una firma o MAC. La firma cubre los dos primeros segmentos codificados, unidos por un punto. Al dividir la cuerda se localizan los segmentos; no puede establecer confianza.
Base64url sin relleno: el alfabeto que usa JWS y por qué los segmentos no tienen signos iguales al final
Base64url usa - y _ en lugar de + y / en Base64 normal. El JWS compacto omite el seguimiento = relleno; un decodificador puede restaurar el relleno antes de decodificar. La decodificación produce bytes. Para encabezados y notificaciones JSON, decodifique los bytes como UTF-8 antes de analizar el texto.
El encabezado: un pequeño objeto JSON que nombra el algoritmo y, a menudo, la clave.
El encabezado suele ser JSON que contiene alg y, a veces, un identificador de clave, kid. Estas son afirmaciones hechas por el propio token. Un verificador debe aplicar su propia política de algoritmos permitidos y obtener de forma segura la clave adecuada; leer alg por sí solo no es autorización.
La carga útil: un objeto JSON de reclamaciones, legible por cualquiera que posea el token
La carga útil contiene reclamaciones como sub, exp y aud. Cualquiera que tenga la ficha puede leerla; codificar no es cifrar. Un exp NumericDate cuenta segundos desde la época de Unix, pero un reclamo no verificado no tiene autoridad. No almacene secretos en una carga útil legible.
La firma: bytes sin procesar en los dos primeros segmentos, sin sentido como texto e inútiles sin una clave.
El último segmento son bytes de firma codificados en base64url, no un tercer objeto JSON. Validarlo requiere un algoritmo criptográfico, una clave y una política de aplicación. ToolAcre deliberadamente no realiza verificación: informa la presencia de firma y siempre marca la firma verificada como falsa.
Ejemplo resuelto: decodificar un token de muestra segmento por segmento, incluido el JSON que aparece
Tome el encabezado de demostración no confidencial {"alg":"HS256","typ":"JWT"} y la carga útil {"sub":"demo"}. Sus codificaciones base64url son eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 y eyJzdWIiOiJkZW1vIn0. La decodificación recupera el JSON. Agregar un tercer segmento arbitrario no hace que el token sea auténtico.
Conclusión: decodificar es leer, no confiar: el decodificador ToolAcre JWT muestra el encabezado y la carga útil y nunca verifica la firma, por lo que nada de lo que muestra demuestra que el token es genuino.
Decodificar es leer, no confiar. Utilice el decodificador ToolAcre JWT para el encabezado, reclamos y advertencias de un token desechable; utilice el verificador confiable de su aplicación para decidir si un token firmado es válido. Los reclamos mostrados por sí solos nunca deben otorgar acceso.