Herramientas de desarrollo · JWT decodificador
Explicación de JWE: Por qué un JWT cifrado tiene cinco partes y ninguna carga útil legible
· Antecedentes
jwt cifrado formatos de datos
Algunos tokens tienen cuatro puntos en lugar de dos y una carga útil que no es JSON. Esta publicación explica la serialización compacta de JWE, lo que contiene cada una de sus cinco partes y por qué ninguna herramienta de decodificación exclusiva puede mostrar sus afirmaciones.
Cuatro puntos y una carga útil que no es JSON: las señales de que tienes un JWE, no un JWS
Cuatro puntos y cinco segmentos indican un sobre compacto diferente del conocido formulario firmado de tres partes. Intentar analizar sus bytes intermedios como afirma JWT produce una tontería porque el contenido es texto cifrado, no una ortografía base64url de texto sin formato JSON.
ToolAcre verifica el recuento de segmentos antes de decodificar. Cinco partes activan un mensaje INVALID_JWT que identifica un JWE y explica por qué no hay nada que esta ruta de solo decodificación pueda mostrar sin una clave de descifrado. Se trata de un límite preciso más que de un vago error de análisis.
Las cinco partes: encabezado protegido, clave cifrada, vector de inicialización, texto cifrado y etiqueta de autenticación
Las partes compactas de JWE representan un encabezado protegido, material de clave cifrada, un valor de inicialización, texto cifrado y una etiqueta de autenticación. Cada uno tiene una función criptográfica distinta. La posición del segmento por sí sola no convierte al segundo o cuarto campo en una carga útil JWT legible.
Un decodificador puede dividir y decodificar en base64url algunos bytes, pero los bytes sin procesar no se descifran. Mostrarlos como texto crearía caracteres de reemplazo o fragmentos engañosos. La acción correcta es identificar el sobre y trasladar la implementación a un destinatario autorizado.
alg y enc: administración de claves versus cifrado de contenido y por qué un encabezado JWE nombra dos algoritmos
Un encabezado JWE puede contener `alg` para administración de claves y `enc` para cifrado de contenido. Estas etiquetas describen diferentes operaciones. Al igual que con los tokens firmados, los valores del encabezado son entradas que deben coincidir con la política del destinatario en lugar del permiso para que el token seleccione algoritmos arbitrarios.
Las notas del algoritmo de tres partes de ToolAcre no implementan el procesamiento JWE y la rama de cinco partes sale antes del análisis del encabezado. Por lo tanto, la página no muestra ni respalda algoritmos de cifrado particulares. Consulte la biblioteca del destinatario y el contrato del emisor para conocer las opciones admitidas.
Claves de cifrado de contenido: cómo una clave aleatoria protege la carga útil y se empaqueta para el destinatario
El cifrado de contenido comúnmente utiliza una clave de cifrado de contenido generada, mientras que el segmento de clave cifrada transmite o deriva esa clave según la disposición del destinatario. La separación permite proteger los bytes de carga útil con un cifrado de contenido, mientras que la política de administración de claves determina quién puede recuperar la clave.
Este modelo conceptual explica por qué poseer la cadena compacta es insuficiente para la recuperación de texto sin formato. Los secretos y la política del destinatario requeridos no están codificados como instrucciones de libre uso. Un decodificador público no puede inventarlos y nunca debería pedir a los usuarios que peguen claves de descifrado privadas en una página genérica.
Cuando los emisores eligen JWE: reclamaciones que deben permanecer confidenciales ante el cliente o los intermediarios
Los emisores pueden seleccionar el cifrado cuando las reclamaciones deben permanecer confidenciales para los titulares o intermediarios que pueden ver un token firmado. Que esa sea la elección correcta depende del modelo de amenaza, la distribución de claves y los requisitos operativos. Minimizar el contenido de las reclamaciones puede seguir siendo preferible a cifrar datos innecesarios.
El cifrado no elimina las preocupaciones sobre autorización, validación o metadatos. El destinatario debe autenticar el contenido protegido y aplicar una política de token después del descifrado. Un resultado legible obtenido por un destinatario autorizado no es automáticamente aceptable para todos los servicios.
Por qué la decodificación se detiene en el encabezado: la carga útil es texto cifrado, por lo que solo el poseedor de la clave puede leerlo
La decodificación se detiene en la estructura porque el posible segmento de carga útil es texto cifrado. ToolAcre evita deliberadamente presentar binarios arbitrarios como JSON y en su lugar proporciona un mensaje específico. Esto evita que los usuarios interpreten galimatías como corrupción en un sobre cifrado que de otro modo sería válido.
Si usted es el destinatario previsto, utilice software controlado configurado con la clave y los algoritmos adecuados. Si no es así, la carga útil ilegible es la propiedad de seguridad esperada. Ningún truco de relleno ni decodificador de caracteres alternativo puede reemplazar el descifrado.
Lo que esto no cubre: JWT anidados que se firman y luego se cifran, y la serialización JWE JSON
Las construcciones anidadas pueden firmar contenido y luego cifrar el resultado, o combinar capas bajo un perfil definido. JWE también tiene representaciones más allá de la cadena compacta de cinco partes. ToolAcre no procesa esos casos y este artículo no infiere el anidamiento simplemente a partir de una etiqueta de encabezado.
Documente qué capa espera su sistema antes de solucionar el problema. De lo contrario, un equipo puede intentar verificar la firma en texto cifrado o decodificar un token interno que no haya sido autenticado. Deje que la biblioteca JOSE seleccionada maneje los pedidos según una política explícita.
Conclusión: un decodificador solo puede mostrar lo que no está cifrado: el decodificador ToolAcre JWT muestra el encabezado y la carga útil de un token firmado; La carga útil de un JWE es ilegible por diseño.
Un decodificador puede mostrar sólo lo que no está cifrado. ToolAcre lee JSON del encabezado y la carga útil de la entrada firmada de tres partes, mientras que cinco segmentos provocan una parada explicativa. Esa distinción evita que una interfaz de sólo decodificación pretenda que tiene capacidad de destinatario.
Utilice el recuento de segmentos como pista de enrutamiento, no como resultado de confianza. Tres partes legibles aún requieren verificación de firma; Cinco partes cifradas requieren descifrado y validación autorizados. En ninguno de los casos, la salida visual por sí sola autentifica las reclamaciones ni otorga acceso.