Decodificador JWT gratuito

Una breve historia de los JSON Web Tokens

El JSON Web Token (JWT) fue estandarizado como RFC 7519 en mayo de 2015 por Michael B. Jones (Microsoft), John Bradley (Ping Identity) y Nat Sakimura (NRI) bajo el Grupo de Trabajo JOSE del IETF. Fue la culminación de media década de trabajo: el primer borrador internet de JWT apareció en diciembre de 2010, surgiendo del pesado formato de aserciones basado en XML de SAML 2.0 (2005) y de la necesidad sentida de algo más ligero que los navegadores pudieran analizar de forma nativa. El gran avance fue elegir JSON sobre XML y base64url sobre PEM: un JWT podía caber en una cadena de consulta URL o en un encabezado Authorization: Bearer. Toda la familia JOSE se entregó como un conjunto coordinado: RFC 7515 (JWS) para firma, RFC 7516 (JWE) para cifrado, RFC 7517 (JWK) para el formato de clave, RFC 7518 (JWA) para identificadores de algoritmo y RFC 7519 (JWT) para la capa de afirmaciones, todos el mismo día de mayo de 2015. La adopción fue instantánea. OAuth 2.0 (RFC 6749, 2012) había estandarizado los tokens de acceso pero dejó su formato opaco; la industria eligió JWT. OpenID Connect (diciembre de 2014, OpenID Foundation) hizo que JWT fuera obligatorio para los tokens ID. Para 2017, todos los principales proveedores de identidad (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) emitían JWT como su formato de sesión nativo. JWT.io, el sitio web decodificador que Auth0 lanzó en 2014, se convirtió en la herramienta de facto para depurar JWT y ayudó a cimentar la cuota mental del formato entre desarrolladores. Dos incidentes de seguridad dieron forma al modelo de amenazas moderno: la divulgación de Tim McLean en 2015 del bypass alg: none y el ataque de confusión de algoritmo HS/RS, y CVE-2022-21449 (abril de 2022), el bug «Psychic Signatures» de Neil Madden en el verificador ECDSA de Java 15-18. Ambos llevaron al endurecimiento por defecto de las bibliotecas: la mayoría de las bibliotecas modernas ahora rechazan alg: none de plano y fijan el algoritmo esperado en lugar de leerlo del encabezado del token.

La anatomía de un JWT

• Tres segmentos codificados en base64url. Un JWT es la cadena header.payload.signature: tres segmentos separados por puntos, cada uno codificado en base64url. La RFC 7519 llama a esto la JWT Compact Serialization. Todo cabe en una URL o un encabezado HTTP; esa compacidad fue el objetivo de diseño que distinguió a JWT de predecesores basados en XML como SAML.
• Encabezado. Un pequeño objeto JSON que normalmente contiene dos campos: alg (el algoritmo de firma, por ejemplo HS256, RS256, ES256) y typ (casi siempre «JWT»). Los campos opcionales incluyen kid (un identificador de clave usado para la rotación de claves) y cty (tipo de contenido para tokens anidados). El encabezado le dice al verificador cómo validar la firma; nunca confíes solo en él, siempre fija el algoritmo esperado del lado del servidor.
• Payload. Un objeto JSON de afirmaciones, aserciones clave-valor sobre un sujeto. La RFC 7519 §4.1 reserva siete afirmaciones estándar: iss (emisor), sub (sujeto), aud (audiencia), exp (expiración), nbf (no antes), iat (emitido en) y jti (ID JWT único). Los emisores añaden afirmaciones personalizadas libremente. El payload está firmado pero no cifrado: cualquiera con el token puede leerlo.
• Firma. La prueba criptográfica de que el encabezado y el payload no han sido manipulados. La entrada de firma es la cadena literal base64url(header) + "." + base64url(payload); la firma misma se codifica luego en base64url como tercer segmento. La verificación requiere el secreto simétrico (HS*) o la clave pública asimétrica (RS*, ES*, PS*, EdDSA) y siempre debe ocurrir en un servidor de confianza.
• base64url, no base64. Los segmentos JWT usan la variante base64 segura para URL definida en la RFC 4648 §5: el carácter 62 es - en lugar de +, el carácter 63 es _ en lugar de /, y el relleno final = se elimina. El atob() incorporado de JavaScript solo maneja base64 estándar, así que los decodificadores JWT traducen el alfabeto y re-rellenan antes de decodificar.
• NumericDate: segundos, no milisegundos. La RFC 7519 define exp, nbf e iat como «el número de segundos desde 1970-01-01T00:00:00Z UTC». El Date.now() de JavaScript devuelve milisegundos, así que un error común es un exp tres órdenes de magnitud demasiado grande, produciendo un token que «expira» alrededor del año 53.000. Usa siempre Math.floor(Date.now() / 1000) al emitir tokens.

Dónde se usan los JWT en la práctica

• Tokens de acceso OAuth 2.0. La RFC 6749 dejó el formato del token de acceso opaco, pero en la práctica la industria se estandarizó en JWT. Auth0, Okta, Azure AD, AWS Cognito y Google Identity emiten todos tokens de acceso JWT por defecto. El token Bearer en tu encabezado Authorization es casi siempre un JWT.
• Tokens ID de OpenID Connect. OIDC (diciembre de 2014) obliga a JWT para su id_token. El id_token lleva afirmaciones de identidad sobre el usuario autenticado (sub, email, name, picture) y es consumido por la parte confiante en lugar de pasarse adelante. Este es el mecanismo principal detrás de «Iniciar sesión con Google», «Iniciar sesión con Apple» y flujos equivalentes.
• Autenticación de API. Las API REST sin estado adoptan JWT porque elimina la necesidad de un almacén de sesiones del lado del servidor: la API confía en lo que la firma verifica. Las claves API estilo Stripe siguen siendo comunes para tráfico servidor-a-servidor, pero para API con alcance de usuario, el patrón Authorization: Bearer <jwt> es ahora el predeterminado.
• Autenticación microservicio-a-microservicio. Un JWT con alcance de usuario emitido en el borde de la API se reenvía a través de llamadas internas servicio-a-servicio, permitiendo que cada servicio confíe en la autenticación original sin re-autenticar. El patrón a veces se llama «traducción de token»: la puerta de enlace de borde intercambia una sesión opaca por un JWT de corta duración con alcance a la llamada descendente.
• Sesiones de aplicaciones de página única. Las SPA (React, Vue, Angular) históricamente almacenaron tokens de acceso en localStorage por conveniencia. La guía moderna (OWASP, Auth0) es mantener los tokens de acceso en memoria y los tokens de refresco en cookies HttpOnly + Secure + SameSite=Strict, porque localStorage es legible por cualquier XSS que aterrice en la página.
• Sesiones de aplicaciones móviles. Las apps de iOS y Android almacenan tokens de acceso en el Keychain o Keystore de la plataforma. El token se envía como Authorization: Bearer en cada llamada al backend. Los tokens de refresco se rotan en cada uso, y el corto exp del token de acceso (típicamente 5-15 minutos) es la defensa principal contra la repetición en caso de dispositivo robado.

Estándares e hitos de seguridad

• RFC 7519 (JWT, mayo de 2015). La especificación base. Define la JWT Compact Serialization, las siete afirmaciones estándar registradas (iss, sub, aud, exp, nbf, iat, jti) y el formato NumericDate. Autores: Michael B. Jones, John Bradley, Nat Sakimura.
• RFC 7515 (JWS, mayo de 2015). JSON Web Signature. El formato de envoltorio firmado que casi todos llaman informalmente «JWT»: tres segmentos base64url unidos por puntos. JWS admite tanto la forma compacta como la JSON Serialization; JWT solo usa la forma compacta.
• RFC 7516 (JWE, mayo de 2015). JSON Web Encryption. La variante cifrada con cinco segmentos (encabezado, clave cifrada, IV, texto cifrado, etiqueta de autenticación). Usa JWE, no JWS, cuando el payload deba ser confidencial, no simplemente evidente ante manipulación.
• RFC 7517 (JWK, mayo de 2015). JSON Web Key. La representación JSON de claves criptográficas. El punto final JWKS (/.well-known/jwks.json) publica un JSON Web Key Set, el mecanismo moderno para rotación de claves sin tiempo de inactividad: los verificadores buscan claves por kid.
• RFC 7518 (JWA, mayo de 2015). JSON Web Algorithms. El registro de identificadores alg: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) y el none (intencionalmente poco usado).
• El bypass alg: none (Tim McLean, 2015). La RFC 7518 lista none como un valor de algoritmo válido para contextos no asegurados. Los verificadores ingenuos aceptaban un token con el encabezado reescrito a {"alg":"none"} y una firma vacía, permitiendo a un atacante falsificar cualquier payload. Las bibliotecas modernas rechazan none por defecto; la propia especificación indica que los verificadores «NO DEBEN aceptar JWS no asegurados por defecto».
• Ataque de confusión de algoritmo HS/RS (Tim McLean, 2015). Si un verificador elige el algoritmo del encabezado del token en lugar de fijarlo, un atacante puede reescribir el encabezado a HS256 y firmar el token usando la clave pública RSA del servidor como secreto HMAC. La biblioteca ve HS256, trata la clave pública RSA configurada como un secreto simétrico, y la firma se verifica. Mitigación: fija el algoritmo esperado fuera de banda; nunca lo derives del token.
• CVE-2022-21449 «Psychic Signatures» (Neil Madden, abril de 2022). El verificador ECDSA de Java 15-18 no comprobaba que los valores r y s de la firma fueran distintos de cero, lo que significa que una firma literal toda en ceros era aceptada como válida. Los JWT firmados con ES256/384/512 en las JVM afectadas podían falsificarse con una firma en blanco. Parcheado en la Actualización Crítica de Parches de Oracle de abril de 2022.

Preguntas frecuentes adicionales

Herramientas relacionadas