Herramientas de desarrollo · JWT decodificador
RFC 7519 y la familia JOSE: JWT, JWS, JWE, JWK y JWA explicados
· Antecedentes
jwt criptografía estándares
JWT es un miembro de una familia de especificaciones del grupo de trabajo IETF JOSE. Esta publicación explica qué define cada RFC, cómo encajan y por qué un JWT suele ser un JWS.
Cinco acrónimos, un token: por qué la documentación menciona JWS y JWE cuando solo preguntaste sobre JWT
La documentación del token se mueve entre JWT, JWS, JWE, JWK y JWA porque describen diferentes capas del mismo ecosistema. La confusión comienza cuando se utiliza “JWT” como abreviatura de cada token firmado compacto de tres partes. Separar los reclamos del sobre y la representación clave hace que sea más fácil razonar sobre la implementación.
El decodificador de ToolAcre es intencionalmente más estrecho que el de la familia. Maneja entradas en forma de JWS de tres partes cuyos primeros dos segmentos decodificados son objetos JSON. Detecta entradas compactas cifradas de cinco partes y se detiene, porque leer texto cifrado sin claves de destinatario no sería decodificar lo mismo.
Los documentos JOSE definen formatos relacionados; este repositorio no establece el cronograma de su grupo de trabajo
Las especificaciones relacionadas provienen del trabajo de IETF JOSE, pero las fuentes del repositorio no establecen el cronograma organizacional detallado solicitado por el esquema. Por lo tanto, este artículo evita inventar fechas o historial de procesos y se concentra en las relaciones de formato observables en la herramienta y el plan.
La pregunta práctica es qué capa posee cada decisión. Los nombres de las notificaciones describen declaraciones de la aplicación, las firmas protegen el material codificado, el cifrado protege el contenido, los objetos clave JSON representan información clave y los identificadores de algoritmos nombran operaciones. Ninguna sigla reemplaza a las demás.
JWS (RFC 7515): firma de contenido arbitrario y serialización compacta que utilizan los JWT
JWS describe contenido firmado o protegido por MAC. Su forma compacta tiene tres segmentos: encabezado protegido, carga útil y firma. La entrada de firma utiliza los dos primeros segmentos codificados unidos por un punto. Un JWT comúnmente viaja en este sobre, que es la forma que ToolAcre divide e inspecciona.
El encabezado y la carga útil pueden decodificarse en JSON, mientras que la firma son bytes en lugar de un tercer objeto. ToolAcre informa la presencia y el tamaño de la firma, pero siempre la marca como no verificada. Por lo tanto, puede ilustrar la estructura JWS sin pretender ningún resultado criptográfico.
JWE (RFC 7516): cifrado de contenido, con una serialización de cinco partes
JWE describe contenido cifrado. Su forma compacta tiene cinco segmentos que representan un encabezado protegido, material de clave cifrada, valor de inicialización, texto cifrado y etiqueta de autenticación. Por lo tanto, cuatro puntos son una fuerte pista estructural de que un decodificador JWT de tres partes ha recibido una envolvente diferente.
ToolAcre emite un error JWE específico y explica que el contenido no se puede leer sin la clave de descifrado. No trata el texto cifrado como JSON con formato incorrecto ni intenta mostrar bytes aleatorios. También se pueden componer el cifrado y la firma, pero el procesamiento anidado queda fuera de esta ruta.
JWK y JWA (RFC 7517 y 7518): representan claves como JSON y nombran los algoritmos
JWK proporciona una representación JSON para información de clave criptográfica, mientras que JWA nombra identificadores de algoritmos y parámetros relacionados utilizados en JOSE. Su existencia no significa que un token pueda elegir su propia clave o algoritmo confiable. Un verificador debe restringir tanto la política del emisor como la de la aplicación.
Las notas del algoritmo ToolAcre explican solo un conjunto finito de etiquetas presentes en la fuente y llaman a cualquier otra cosa no reconocida. Son descripciones, no implementaciones. El decodificador no importa un JWK ni realiza un algoritmo desde JWA, lo que mantiene explícito el límite de inspección.
JWT (RFC 7519): el formato de reclamos que se basa en JWS o JWE
JWT define un objeto de reclamos y nombres registrados como emisor, asunto, audiencia y fechas numéricas. Esos reclamos pueden llevarse en una estructura JOSE firmada o cifrada. Por lo tanto, la capa de carga útil responde "qué declaraciones se representan", mientras que el sobre responde cómo se protegen u ocultan esos bytes.
ToolAcre espera que la carga útil decodificada sea un objeto JSON y enumera sus reclamaciones. Una matriz, un número o un valor nulo se rechazan para esta herramienta. Incluso un objeto con buena forma sigue siendo poco fiable hasta que un verificador o destinatario configurado procesa el sobre correspondiente.
Lo que esto no cubre: los perfiles posteriores, como las mejores prácticas de RFC 8725 y los tokens de acceso de RFC 9068, que tienen sus propias publicaciones.
Los documentos posteriores sobre mejores prácticas y perfiles pueden limitar cómo se deben utilizar estos mecanismos generales. Merecen un tratamiento separado porque un formato base no proporciona una política de tipo de token, audiencia o emisor específico de la aplicación. Este artículo no afirma que el decodificador implemente dicho perfil.
Al revisar un sistema, escriba el perfil exacto, el sobre esperado, los algoritmos aceptados, la fuente clave y las reglas de reclamo. Esa lista evita que la familiaridad con las siglas se convierta en una suposición de compatibilidad o seguridad.
Conclusión: JWT son los reclamos, JWS es el sobre: el decodificador ToolAcre JWT lee el formulario compacto JWS y muestra el encabezado JWT y los reclamos en su interior
JWT nombra la capa de reclamos; JWS y JWE proporcionan sobres de protección; JWK representa datos clave; JWA nombra opciones de algoritmos. ToolAcre lee la forma común firmada de tres partes y muestra el encabezado y los reclamos mientras se niega a verificar o descifrar.
Utilice ese mapa para hacer la siguiente pregunta correcta. JSON legible identifica la capa de reclamo. Tres o cinco segmentos identifican posibles familias envolventes. La confianza todavía depende de la criptografía y la política configuradas de forma independiente, no de que el descodificador reconozca un acrónimo.