Un token JWT, abreviatura de JSON Web Token, es un formato compacto para pasar declaraciones entre dos partes. Las aplicaciones utilizan comúnmente los JWT después del inicio de sesión: un servidor emite un token, el cliente lo envía en solicitudes posteriores y una API verifica el token antes de permitir el acceso. Un JWT no es un token de criptomoneda y su contenido no es automáticamente secreto.
Los sistemas de cuentas en finanzas, exchanges y servicios Web3 pueden utilizar autenticación basada en tokens de forma interna. Los lectores que exploran plataformas de activos digitales pueden crear una cuenta en Tapbit, mientras que los desarrolladores deben tratar cada token de autenticación como una credencial sensible a la seguridad.
¿Qué es un token JWT?
El estándar JWT, RFC 7519, define un formato de declaración compacto diseñado para su transmisión como un objeto JSON. Una declaración es una afirmación como un identificador de usuario, el emisor del token, la audiencia prevista o la hora de expiración. Los JWT se utilizan a menudo como tokens de acceso, tokens de identidad o mensajes de corta duración entre servicios.
La gente a menudo dice “token JWT”, aunque la “T” final ya significa token. La repetición es común e inofensiva. Lo importante es entender que JWT describe un formato, no un sistema de inicio de sesión completo. La autenticación segura también requiere políticas correctas de emisión, validación, almacenamiento, expiración y revocación.
¿Cómo funciona un JSON Web Token?
Un flujo de inicio de sesión típico comienza cuando un usuario envía credenciales válidas. El servidor de autenticación crea un JWT que contiene declaraciones seleccionadas y lo protege con una firma digital o un código de autenticación de mensajes. Luego, el cliente presenta el JWT a una API, a menudo en una cabecera HTTP Authorization utilizando el esquema Bearer.
La API verifica la firma y comprueba las declaraciones requeridas antes de confiar en la solicitud. Las comprobaciones importantes pueden incluir el emisor, la audiencia, la hora de expiración y el algoritmo esperado por la aplicación. Si la verificación tiene éxito, la API utiliza las declaraciones para tomar una decisión de autorización. Si falla, la solicitud debe ser rechazada.
Las tres partes de un JWT
Un JWT firmado comúnmente visto tiene tres secciones codificadas en Base64url separadas por puntos:
header.payload.signature
- Cabecera (Header): identifica el tipo de token y el algoritmo de firma.
- Carga útil (Payload): contiene declaraciones, como
subpara sujeto,isspara emisor,audpara audiencia yexppara expiración. - Firma (Signature): permite al destinatario detectar cambios no autorizados y verificar al firmante cuando se utiliza la clave correcta.
La codificación Base64url no es cifrado. Cualquiera que obtenga un JWT firmado normal generalmente puede decodificar su cabecera y carga útil. Por lo tanto, la información sensible no debe colocarse en la carga útil a menos que el sistema utilice un formato cifrado apropiado y tenga una necesidad clara para ello.
Ejemplo de JWT para principiantes
Considere una API que emite un token después de que Alice inicia sesión. Su carga útil podría identificar a Alice como el sujeto, nombrar al emisor, especificar la audiencia de la API y expirar en 15 minutos. Cuando Alice solicita su perfil, la API valida el token y utiliza la declaración del sujeto para localizar la cuenta correcta.
Si alguien cambia la carga útil del identificador de Alice por el de un administrador, la firma ya no coincidirá. Ese es el beneficio principal de un JWT firmado: la manipulación se vuelve detectable. Sin embargo, una firma válida no prueba que cada declaración sea apropiada. La API aún debe confirmar que el token provino del emisor esperado y estaba destinado a esa API.
JWT vs Cookies de Sesión vs Claves API
| Método | Propósito típico | Dónde reside el estado | Consideración principal |
|---|---|---|---|
| JWT | Declaraciones y autorización de API | El token lleva las declaraciones; los servidores aún pueden mantener el estado | Diseño de validación y revocación |
| Cookie de sesión | Sesión de inicio de sesión del navegador | Generalmente almacena sesiones del lado del servidor | Protecciones de cookies y CSRF |
| Clave API | Identificar una aplicación o proyecto | El servidor mapea la clave a los permisos | Las claves son secretos de larga duración a menos que se roten |
Los JWT no son automáticamente mejores que las sesiones. Las sesiones pueden hacer que la revocación inmediata sea sencilla, mientras que los JWT pueden reducir las búsquedas repetidas en la base de datos y funcionar bien en servicios distribuidos. Muchos sistemas combinan ambos enfoques, como un JWT de corta duración con un registro de token de actualización administrado por el servidor.
¿Están cifrados los JWT?
Generalmente no. El JWT familiar de tres partes es comúnmente un objeto JSON Web Signature firmado. La firma proporciona integridad y autenticidad cuando se implementa correctamente, pero no oculta la carga útil. JSON Web Encryption es un estándar relacionado que puede proporcionar confidencialidad, aunque utiliza una estructura diferente y añade complejidad en la gestión de claves.
Esta distinción es importante porque los desarrolladores a veces pegan un JWT en un decodificador y se sorprenden al ver datos legibles. La decodificación no es lo mismo que verificar la firma con éxito. Las aplicaciones nunca deben conceder acceso basándose únicamente en declaraciones decodificadas.
Riesgos de seguridad comunes de JWT
Las Mejores Prácticas Actuales para JWT de la IETF, RFC 8725, abordan fallos de implementación que han aparecido en sistemas reales. Los problemas más grandes suelen provenir de una validación incorrecta en lugar del formato básico en sí.
- Confusión de algoritmos: aceptar un algoritmo inesperado o inseguro.
- Falta de comprobaciones de declaraciones: ignorar el emisor, la audiencia, la expiración u otros requisitos de la aplicación.
- Robo de tokens: exponer un token bearer a través de registros, scripts, almacenamiento inseguro o transporte desprotegido.
- Claves débiles: usar secretos predecibles o no rotar las claves de firma comprometidas.
- Expiración larga: dejar que los tokens robados sean útiles durante demasiado tiempo.
- Mala revocación: asumir que un token firmado nunca necesitará invalidación temprana.
Mejores prácticas para JWT
Las aplicaciones deben permitir explícitamente solo los algoritmos que admiten, verificar cada declaración requerida y utilizar reglas de validación separadas para diferentes tipos de JWT. Los tokens deben ser de corta duración, transmitirse solo a través de HTTPS y excluirse de las URL y los registros rutinarios. Las claves de firma necesitan almacenamiento seguro, rotación y propiedad clara.
El almacenamiento depende de la aplicación. Los sistemas de navegador pueden usar cookies seguras, HttpOnly y SameSite, mientras que los clientes móviles o de backend utilizan almacenamiento protegido apropiado para la plataforma. Ninguna opción de almacenamiento elimina todas las amenazas, por lo que los desarrolladores deben considerar juntos los ataques de Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), la reproducción de tokens y el compromiso del dispositivo.
Conclusión
Un JWT es una forma compacta de transportar declaraciones verificables entre sistemas. Su cabecera describe cómo está protegido, su carga útil contiene declaraciones y su firma ayuda a los destinatarios a detectar manipulaciones. Los JWT pueden simplificar la autenticación de API, pero solo cuando el destinatario verifica el algoritmo, emisor, audiencia, declaraciones de tiempo y firma correctos. Para los principiantes, la regla clave es simple: un JWT es un formato de credencial, no una prueba de que todo el diseño de autenticación sea seguro.
Preguntas frecuentes
¿Qué significa JWT?
JWT significa JSON Web Token, un formato compacto estandarizado para transmitir declaraciones como JSON.
¿Puede cualquiera decodificar un JWT?
Cualquiera que tenga un JWT firmado típico generalmente puede decodificar su cabecera y carga útil. La decodificación no verifica la firma ni hace que las declaraciones sean confiables.
¿Es un JWT lo mismo que un token de acceso?
No. Un token de acceso describe un propósito, mientras que JWT describe un formato. Algunos tokens de acceso son JWT y otros son cadenas opacas.
¿Cuánto tiempo debe durar un JWT?
No hay una duración universal. Los tokens de acceso suelen ser de corta duración, con una vida útil exacta basada en los requisitos de riesgo, revocación y usabilidad del sistema.
¿Se puede revocar un JWT?
Sí, pero la revocación requiere un diseño adicional, como una lista de denegación, rotación de claves, versionado de tokens o un sistema de tokens de actualización administrado por el servidor.
