Decodificador y codificador JWT

Un decodificador JWT, también llamado analizador, depurador o visor de JWT, es una herramienta que divide un token web JSON en tres partes: encabezado, carga útil y firma, y ​​muestra cada una como JSON legible. Un codificador JWT hace lo contrario: toma un encabezado, una carga útil y una clave de firma, y ​​produce un token compacto firmado. JSON Web Token (JWT, pronunciado "jot") es un estándar abierto definido por el IETF en RFC 7519 para transmitir reclamaciones verificadas entre dos partes como una cadena compacta y segura para URL.

Los JWT son la base de la autenticación sin estado en la arquitectura web moderna. Después de que un usuario inicia sesión, el servidor de autorización emite un JWT firmado que contiene reclamos verificados (una identificación de usuario, función, tiempo de vencimiento) y lo devuelve al cliente. El cliente adjunta ese token a cada solicitud de API posterior. El servidor verifica la firma digital sin consultar un almacén de sesiones, lo que hace que el sistema sea rápido y escalable a través de microservicios. En la mayoría de los sistemas, un token de acceso de corta duración y un token de actualización de mayor duración se emiten juntos: el token de acceso contiene los reclamos JWT, mientras que el token de actualización se usa para solicitar uno nuevo después de su vencimiento.

Los dos protocolos más comunes que dependen de JWT son OAuth 2.0 (autorización) y OpenID Connect (OIDC – identidad y autenticación). En ambos, los JWT llevan afirmaciones estandarizadas definidas en RFC 7519. Google, Microsoft, Okta y Auth0 emiten tokens de identificación OIDC como JWT.

A diferencia del paquete npm jwt-decode, que solo decodifica tokens, esta herramienta también codifica y decodifica tokens con cualquier algoritmo HMAC o RSA, verifica firmas y genera claves secretas, todo sin salir de su navegador. Las principales bibliotecas JWT en otros lenguajes incluyen PyJWT (Python), jjwt (Java), golang-jwt (Go) y jose (Rust). Utilice esta herramienta para probar los tokens generados por cualquiera de ellos.

Un JWT son tres cadenas codificadas en Base64URL unidas por puntos: [encabezado].[carga útil].[firma]. Cuando codifica un JWT, cada sección está codificada en Base64URL y unida con puntos. Cuando lo decodifica, cada sección se separa y se muestra como JSON. El encabezado identifica el algoritmo. La carga útil lleva los reclamos. La firma demuestra que ninguno de los dos ha sido alterado.

Aquí hay un token JWT de muestra que muestra cómo se dividen las tres partes:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9          ← encabezado
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ  ← carga útil
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← firma

Pegue este JWT de muestra en el decodificador de arriba para ver cada parte decodificada.

Los reclamos registrados en JWT son nombres de campos estandarizados definidos en RFC 7519. Los más importantes son exp (tiempo de vencimiento), sub (asunto, generalmente una identificación de usuario), iss (emisor) y aud (audiencia). Todos son opcionales pero se implementan ampliamente en los sistemas OAuth 2.0 y OIDC.

Nombres de reclamos registrados RFC 7519: opcionales pero ampliamente admitidos en los sistemas OAuth 2.0 y OIDC:

Los valores de NumericDate (exp, nbf, iat) son segundos desde la época de Unix: 00:00:00 UTC del 1 de enero de 1970.

Cuando codifique un JWT, agregue reclamaciones privadas para datos específicos de la aplicación: roles, nivel de suscripción, ID de organización, alcances de permisos. Utilice un nombre de estilo URI como "https://yourapp.com/role" para evitar futuras colisiones del registro de la IANA.

Esta herramienta admite las tres variantes de HMAC (HS256, HS384, HS512) y las seis variantes RSA/RSA-PSS (RS256, RS384, RS512, PS256, PS384, PS512), como se define en RFC 7518 (Algoritmos web JSON). Elija HMAC para configuraciones de servicio único; elija RSA para sistemas distribuidos donde los servicios verifican tokens sin compartir la clave de firma.

JWT es seguro cuando se implementa correctamente. Tres vulnerabilidades aparecen constantemente en las auditorías de seguridad de API: la omisión de alg:none, confusión de algoritmos y secretos HMAC débiles. Todo se debe a errores de implementación, no a fallas en RFC 7519. RFC 8725 (JWT Best Current Practices, IETF) proporciona la guía de mitigación autorizada.

Los JWT no tienen estado: todos los datos de la sesión están codificados en el token. La autenticación basada en sesiones almacena los datos de la sesión en el lado del servidor y le proporciona al cliente solo una ID de sesión. Los JWT escalan mejor horizontalmente; Las sesiones admiten la revocación instantánea.

Elija JWT para API distribuidas, microservicios, aplicaciones móviles, inicio de sesión único (SSO) y cualquier arquitectura en la que varios servicios independientes necesiten verificar tokens sin compartir un almacén de sesiones.

Elija sesiones para aplicaciones que requieran una revocación inmediata de tokens (sistemas financieros, herramientas de administración), aplicaciones web tradicionales renderizadas por servidor o sistemas donde el tamaño del token es una restricción.