JWT es un formato estandarizado para representar y transmitir información entre sistemas mediante un token compacto compuesto por datos codificados y una firma que permite comprobar su integridad. Sus siglas proceden de JSON Web Token y se utiliza con frecuencia en autenticación, autorización, APIs, aplicaciones web, aplicaciones móviles y arquitecturas distribuidas.
Un JWT puede incluir información sobre el usuario, el emisor, la audiencia, el momento de creación y la fecha de expiración. El servidor que lo recibe puede verificar su firma y decidir si acepta la solicitud sin consultar necesariamente una sesión almacenada en cada petición.
Esta característica ha convertido JWT en una solución habitual para access tokens, comunicación entre servicios y sistemas donde varios componentes necesitan interpretar una identidad o unos permisos. Sin embargo, no significa que JWT sea siempre la mejor alternativa ni que elimine la necesidad de controlar sesiones, revocaciones, permisos y seguridad.
En Aula CM vemos errores recurrentes cuando se implementa JWT como si fuera simplemente una cadena secreta. Un token puede estar firmado y seguir exponiendo su contenido a cualquiera que lo copie. También puede ser técnicamente válido y conceder permisos que el usuario ya no debería tener. La implementación profesional necesita comprender qué contiene el token, quién lo emite, cómo se verifica, dónde se almacena y qué ocurre cuando debe invalidarse.
Qué Es JWT
JWT es un estándar abierto que define una forma compacta y segura de representar declaraciones entre dos partes. Estas declaraciones, conocidas como claims, se expresan mediante objetos JSON y pueden protegerse con una firma digital o un código de autenticación.
El token suele viajar dentro de una petición HTTP, normalmente en una cabecera de autorización. El sistema receptor lo separa en sus componentes, comprueba la firma, valida sus claims y determina si puede ejecutar la acción solicitada.
La palabra “segura” necesita matizarse. Un JWT firmado permite detectar si el contenido ha sido modificado, pero no oculta automáticamente sus datos. La cabecera y el payload suelen estar codificados en Base64URL, una representación que puede revertirse con facilidad.
Por eso nunca deberían incluirse contraseñas, secretos, datos bancarios ni información sensible que no pueda quedar expuesta. Firmar un token no equivale a cifrarlo.
Qué Significa JWT
JWT significa JSON Web Token. JSON es el formato utilizado para representar la información; web indica que fue diseñado para funcionar bien en entornos web; y token describe el elemento que se intercambia entre sistemas.
El nombre no implica que solo pueda utilizarse en una página web. También aparece en aplicaciones móviles, APIs, microservicios, integraciones, dispositivos y comunicaciones entre servidores.
En documentación técnica puede encontrarse como JWT token, aunque la expresión repite la palabra token. En el uso cotidiano es habitual y se entiende sin problemas.
La pronunciación varía entre equipos. Algunas personas dicen las letras por separado y otras pronuncian una forma similar a “jot”. La diferencia no cambia el concepto técnico.
Qué Es un Token JWT
Un token JWT es una cadena compacta que contiene declaraciones estructuradas y una firma. Normalmente presenta tres bloques separados por puntos: header, payload y signature.
El header indica el tipo de token y el algoritmo utilizado. El payload contiene los claims. La signature permite verificar que los dos bloques anteriores no han sido modificados y que proceden de una fuente que posee la clave adecuada.
El token puede representar una autenticación, un permiso temporal, una identidad de servicio o información que otro sistema necesita validar.
No todos los JWT representan usuarios. Un servicio puede emitir un token para que otro servicio acceda a una API, o para confirmar una operación concreta durante un periodo limitado.
Para Qué Sirve JWT
JWT sirve para transmitir información verificable entre sistemas. Su uso más conocido es la autenticación en APIs, aunque también puede utilizarse para autorización, intercambio de claims y comunicación entre servicios.
Después de iniciar sesión, un servidor puede emitir un access token. La aplicación lo envía en solicitudes posteriores y el servidor verifica que sigue siendo válido antes de responder.
También puede incluir permisos o roles, aunque el sistema debe decidir con cuidado qué información confía al token y cuánto tiempo puede permanecer sin actualizarse.
La utilidad principal no consiste en “recordar al usuario”, sino en transportar un conjunto de declaraciones cuya integridad puede comprobarse.
Autenticar solicitudes
El token permite asociar una petición con una identidad previamente autenticada. El servidor comprueba la firma, la expiración, el emisor y otras condiciones.
Si las validaciones son correctas, puede tratar la solicitud como perteneciente al sujeto indicado en el token.
Autorizar acciones
El JWT puede incluir roles, scopes o permisos que ayuden a determinar qué operaciones están disponibles.
Sin embargo, los permisos críticos deberían contrastarse con el estado actual del sistema cuando puedan cambiar antes de que expire el token.
Comunicar microservicios
En una arquitectura distribuida, varios servicios pueden verificar tokens emitidos por un proveedor de identidad común.
Esto reduce la necesidad de consultar un almacén de sesión central en cada petición, aunque exige una gestión rigurosa de claves y audiencias.
Integrar aplicaciones y APIs
Las APIs pueden recibir tokens para identificar al cliente, conocer el alcance autorizado y rechazar peticiones no válidas.
El token debe viajar siempre mediante conexiones seguras y limitarse al servicio para el que fue emitido.
Transportar declaraciones verificables
Un sistema puede emitir información que otro necesita comprobar, como el identificador de una operación, el emisor y el periodo de validez.
El receptor no debería confiar únicamente en que el contenido “parece correcto”. Debe verificar la firma y todas las condiciones relevantes.
Cómo Funciona JWT
JWT funciona mediante la creación, entrega y validación de un token. El emisor construye una cabecera y un payload, los codifica y genera una firma utilizando una clave.
La aplicación cliente recibe el token y lo presenta cuando necesita acceder a un recurso protegido. El servidor receptor vuelve a calcular o comprobar la firma y valida las declaraciones.
Si el token ha sido modificado, la firma no coincide. Si ha expirado, pertenece a otra audiencia, procede de un emisor no confiable o utiliza un algoritmo no aceptado, debe rechazarse.
La verificación no consiste solo en comprobar la firma. Una firma válida confirma integridad y procedencia respecto a una clave, pero no garantiza que el token sea apropiado para cualquier servicio ni que deba seguir aceptándose.
1. El usuario se autentica
La persona envía credenciales o utiliza otro mecanismo de autenticación. El servidor comprueba su identidad.
JWT no sustituye esta primera comprobación. El token se emite después de que el sistema haya decidido confiar en la identidad.
2. El servidor genera el token
El emisor crea los claims, selecciona un algoritmo y genera la firma con la clave correspondiente.
La duración, la audiencia y el alcance deben ajustarse al riesgo y al tipo de operación.
3. El cliente recibe el JWT
La aplicación conserva el token durante el tiempo necesario. El mecanismo de almacenamiento afecta directamente a la seguridad.
No existe una ubicación universalmente correcta. La elección depende de la arquitectura, la protección frente a XSS, el riesgo de CSRF y el tipo de cliente.
4. El cliente envía el token
En una API suele presentarse como bearer token dentro de la cabecera de autorización.
Bearer significa que quien posee el token puede utilizarlo. Por eso debe protegerse igual que una credencial durante su periodo de validez.
5. El servidor verifica el JWT
El receptor comprueba firma, algoritmo, emisor, audiencia, expiración y cualquier otra regla del sistema.
Después extrae la identidad y aplica sus controles de autorización.
6. El servidor responde
Si el token y los permisos son válidos, procesa la solicitud. Si no lo son, devuelve un error adecuado sin revelar información innecesaria.
Estructura de un JWT
Un JWT firmado suele estar formado por tres partes: header, payload y signature. Cada bloque utiliza Base64URL y se separa mediante un punto.
- Header: describe el tipo de token y el algoritmo.
- Payload: contiene los claims.
- Signature: protege la integridad del header y el payload.
Esta estructura compacta facilita su transporte en cabeceras HTTP y otros canales. Sin embargo, un token puede crecer mucho si contiene demasiados claims.
Un JWT excesivamente grande aumenta el tráfico, puede superar límites de cabeceras y expone más información. Conviene incluir solo los datos necesarios.
Qué Es el Header de un JWT
El header es la cabecera del token. Suele indicar el algoritmo de firma y el tipo de objeto.
También puede incluir un identificador de clave para ayudar al receptor a seleccionar la clave pública adecuada cuando existen rotaciones o varios emisores.
El algoritmo indicado dentro del token no debería aceptarse ciegamente. El servidor debe tener una lista explícita de algoritmos permitidos.
Confiar en cualquier algoritmo declarado por el cliente puede abrir vulnerabilidades, especialmente si la biblioteca o la configuración permiten combinaciones inseguras.
Qué Es el Payload de un JWT
El payload es la parte que contiene las declaraciones. Puede incluir identificador del sujeto, emisor, audiencia, expiración, roles y otros datos.
El payload no está oculto en un JWT firmado convencional. Cualquier persona que obtenga el token puede decodificarlo y leerlo.
Por eso debe evitarse incluir datos que no sean necesarios para el receptor. Incluso información aparentemente inofensiva puede facilitar reconocimiento de usuarios, arquitectura o permisos.
La presencia de un claim tampoco garantiza que sea cierto. Solo puede confiarse después de verificar la firma y confirmar que el emisor es válido.
Qué Es la Firma de un JWT
La firma protege la integridad del token. Se calcula a partir del header y el payload codificados, utilizando una clave y un algoritmo.
Si alguien modifica un claim, la firma deja de corresponder con el contenido. El receptor detecta la alteración durante la verificación.
Con algoritmos simétricos, emisor y receptor comparten el mismo secreto. Con algoritmos asimétricos, el emisor firma con una clave privada y los receptores verifican con una clave pública.
La firma no impide copiar y reutilizar un token válido. La expiración, la revocación y la protección durante el transporte siguen siendo necesarias.
Qué Es un Claim JWT
Un claim es una declaración incluida dentro del payload. Representa información que el emisor afirma sobre el token, el sujeto o el contexto.
Existen claims registrados con significados estandarizados, claims públicos y claims privados definidos entre sistemas.
Un claim puede indicar quién es el usuario, quién emitió el token, para qué servicio sirve y cuándo expira.
Los nombres privados necesitan una convención clara para evitar colisiones y diferencias de interpretación entre aplicaciones.
Claims Registrados de JWT
Los claims registrados son nombres estandarizados que permiten expresar propiedades comunes del token.
- iss: identifica al emisor.
- sub: identifica al sujeto.
- aud: indica la audiencia prevista.
- exp: establece la expiración.
- nbf: indica desde cuándo puede aceptarse.
- iat: registra cuándo fue emitido.
- jti: asigna un identificador único al token.
No todos son obligatorios en cualquier implementación, pero emisor, audiencia y expiración suelen ser especialmente importantes en sistemas reales.
Qué Es exp en JWT
El claim exp indica el momento a partir del cual el token debe dejar de aceptarse. Define su fecha de expiración.
Un access token debería tener una duración limitada. Cuanto más tiempo permanezca válido, mayor será el impacto si se roba.
La duración depende del riesgo, la experiencia y la posibilidad de renovación. No existe un valor universal válido para todas las aplicaciones.
El servidor debe validar exp en cada petición protegida y considerar un margen pequeño para diferencias de reloj entre sistemas.
Qué Es iat en JWT
Iat significa issued at e indica el momento en el que se emitió el token.
Puede ayudar a determinar su antigüedad, aplicar políticas y analizar incidentes.
Por sí solo no establece cuándo expira. Debe combinarse con exp u otras reglas.
El receptor tampoco debería confiar en valores temporales sin verificar el emisor y la firma.
Qué Es nbf en JWT
Nbf significa not before e indica que el token no debe aceptarse antes de un momento concreto.
Puede utilizarse para permisos que comienzan en el futuro o procesos con una ventana temporal determinada.
Una diferencia de reloj entre servidores puede provocar rechazos inesperados. Conviene sincronizar los sistemas y utilizar una tolerancia controlada.
No debería aplicarse una tolerancia excesiva porque ampliaría la ventana real de validez.
Qué Es aud en JWT
Aud significa audience e identifica los destinatarios para los que se emitió el token.
Un servicio no debería aceptar un JWT destinado a otra API, aunque la firma pertenezca a un emisor conocido.
Validar la audiencia ayuda a impedir que un token obtenido para un recurso se reutilice en otro.
En arquitecturas con varios servicios, las audiencias deben diseñarse y documentarse con claridad.
Qué Es iss en JWT
Iss significa issuer e identifica al emisor del token.
El receptor debe aceptar únicamente emisores configurados como confiables. No basta con que el valor sea una URL con apariencia legítima.
La validación se relaciona con las claves utilizadas, la configuración del proveedor de identidad y el contexto de la aplicación.
En sistemas con varios entornos, conviene evitar que tokens de desarrollo sean aceptados en producción.
Qué Es sub en JWT
Sub significa subject e identifica al sujeto principal del token. A menudo representa a un usuario, aunque también puede corresponder a un servicio.
Conviene utilizar un identificador estable y no depender de datos que puedan cambiar, como el email.
El sistema puede utilizar sub para localizar información actual y aplicar permisos.
No debería mostrarse o interpretarse como prueba suficiente sin validar todo el token.
Qué Es jti en JWT
Jti significa JWT ID y proporciona un identificador único al token.
Puede utilizarse para evitar reutilizaciones, registrar emisiones o mantener listas de revocación.
Su utilidad depende de que el sistema almacene y compruebe esos identificadores. Incluirlo sin ningún proceso asociado no añade protección por sí solo.
En operaciones de un solo uso, el receptor puede registrar que un jti ya fue consumido y rechazar intentos posteriores.
JWT Está Codificado o Cifrado
Un JWT firmado habitual está codificado, no cifrado. Header y payload utilizan Base64URL para poder transportarse como texto.
La codificación no protege la confidencialidad. Cualquier persona puede revertirla y leer los datos.
La firma protege integridad y autenticidad respecto a la clave utilizada. No oculta el contenido.
Cuando se necesita confidencialidad puede utilizarse un formato cifrado adecuado o evitar transportar información sensible en el token.
Diferencia Entre Codificar, Firmar y Cifrar un JWT
- Codificar: transforma el formato para facilitar el transporte.
- Firmar: permite detectar modificaciones y verificar al emisor.
- Cifrar: impide leer el contenido sin la clave adecuada.
Estas operaciones resuelven problemas distintos. Base64URL no es una técnica de seguridad.
Un error frecuente consiste en abrir un token, ver caracteres difíciles de leer y asumir que la información está cifrada.
Qué Es JWT Decode
JWT decode es el proceso de separar el token y convertir sus bloques codificados en una representación legible.
Decodificar permite inspeccionar header y payload sin conocer la clave de firma.
Esta operación resulta útil para depuración, pero no confirma que el token sea auténtico ni válido.
Una aplicación nunca debería conceder acceso únicamente porque ha podido decodificar un JWT y sus datos parecen correctos.
Qué Es un JWT Decoder
Un JWT decoder es una herramienta o biblioteca que muestra el contenido del token de forma legible.
Puede presentar el algoritmo, los claims, las fechas y la estructura.
Algunas herramientas también permiten verificar una firma si se proporciona una clave. Esa verificación debe distinguirse claramente de la simple decodificación.
No conviene pegar tokens reales de producción en servicios online desconocidos. Pueden contener información identificativa o conceder acceso durante su vigencia.
Cómo Decodificar un JWT
Para decodificar un token se separan sus bloques y se interpreta la codificación Base64URL de header y payload.
Muchas bibliotecas y herramientas realizan el proceso automáticamente.
Después conviene revisar algoritmo, emisor, audiencia, sujeto, expedición y expiración.
La inspección solo sirve como diagnóstico. Para aceptar el token debe utilizarse una biblioteca que verifique firma y claims de forma segura.
Qué Es JWT.io
JWT.io es una herramienta conocida para inspeccionar la estructura de JSON Web Tokens, consultar documentación y probar determinadas verificaciones.
Resulta útil para aprendizaje y depuración porque separa header, payload y signature.
No debería utilizarse para compartir tokens reales con datos sensibles o credenciales activas.
En entornos profesionales conviene utilizar tokens de prueba y verificar siempre el comportamiento con las bibliotecas del proyecto.
Cómo Verificar un JWT
Verificar un JWT implica comprobar la firma y validar todas las condiciones necesarias para el contexto.
- Algoritmo permitido.
- Clave correcta.
- Firma válida.
- Emisor confiable.
- Audiencia correcta.
- Token no expirado.
- Inicio de validez cumplido.
- Permisos adecuados.
- Token no revocado.
La aplicación debe fallar de forma segura. Si una validación no puede completarse, el token no debería aceptarse.
JWT Authentication
JWT authentication es un modelo en el que el sistema utiliza JSON Web Tokens para representar una autenticación ya realizada.
El usuario introduce credenciales, el servidor las valida y emite un token. Las solicitudes posteriores presentan ese token.
JWT no define por sí solo cómo se realiza el login, cómo se recupera una cuenta, cómo se aplica segundo factor ni cómo se protege una contraseña.
Es una pieza dentro del sistema de autenticación, no una solución completa de identidad.
Qué Es JWT Auth
JWT auth es una expresión abreviada para referirse a autenticación o autorización basada en tokens JWT.
Puede aparecer en paquetes, bibliotecas y documentación de frameworks.
El término no garantiza que todas las implementaciones funcionen igual. Algunas utilizan cookies, otras bearer tokens y otras combinan access y refresh tokens.
Antes de integrar una librería conviene revisar su mantenimiento, algoritmos, gestión de claves, renovación y compatibilidad con el framework.
Diferencia Entre Autenticación y Autorización con JWT
La autenticación responde a quién es el usuario o servicio. La autorización decide qué puede hacer.
El JWT puede transportar información útil para ambas, pero deben mantenerse como decisiones separadas.
Un token firmado puede identificar a una persona correctamente y aun así no concederle permiso para eliminar un recurso.
Los endpoints deben aplicar controles de autorización en el servidor y no confiar en que la interfaz o el cliente oculten determinadas acciones.
Qué Es un Bearer Token
Un bearer token es una credencial que puede utilizar quien la posee. No exige demostrar una clave adicional en cada petición.
Muchos access tokens JWT se envían como bearer tokens.
Esto facilita la integración, pero aumenta la importancia de protegerlos frente a robo, registros, URLs, extensiones, scripts y conexiones inseguras.
Nunca deberían enviarse en parámetros de URL cuando pueden quedar expuestos en historiales, logs y referencias.
Qué Es un Access Token JWT
Un access token JWT concede acceso temporal a recursos y operaciones según sus claims y las reglas del servidor.
Debería tener una duración limitada y un alcance ajustado.
El receptor debe validar audiencia, emisor, firma, expiración y permisos.
El access token no debería utilizarse como almacén de toda la información del usuario. Puede contener un identificador y los datos mínimos necesarios.
Qué Es un Refresh Token
Un refresh token es una credencial utilizada para obtener un nuevo access token cuando el anterior expira.
Suele tener una duración mayor y, por tanto, necesita medidas de protección superiores.
No tiene por qué ser un JWT. Puede ser una cadena opaca asociada con un registro almacenado en el servidor.
El sistema debería permitir revocarlo, rotarlo y detectar reutilizaciones anómalas.
JWT Refresh Token
Un refresh token basado en JWT contiene claims y una firma, igual que otros JSON Web Tokens.
Esta opción permite validación distribuida, pero complica la revocación si se quiere invalidar antes de la expiración.
Muchas arquitecturas prefieren refresh tokens opacos almacenados de forma segura para mantener mayor control sobre las sesiones.
La decisión depende del proveedor de identidad, los clientes, la escala y el modelo de riesgo.
Diferencia Entre Access Token y Refresh Token
- Access token: se presenta ante APIs y dura poco tiempo.
- Refresh token: permite solicitar nuevos access tokens y dura más.
El refresh token no debería enviarse a todas las APIs ni quedar accesible en lugares innecesarios.
Separar ambas credenciales limita el impacto de un access token robado y permite renovar sesiones sin pedir credenciales constantemente.
Cómo Renovar un JWT
Un JWT firmado no se modifica ni amplía su expiración. Para renovarlo se emite un token nuevo.
El cliente presenta un refresh token o vuelve a autenticarse. El servidor comprueba la sesión y genera otro access token.
Durante la renovación conviene revisar si la cuenta sigue activa, si los permisos han cambiado y si el refresh token continúa siendo válido.
La rotación de refresh tokens ayuda a detectar robos: cada uso genera uno nuevo y anula el anterior.
Qué Significa JWT Expirado
Un JWT expirado ha superado el momento indicado en exp y debe rechazarse.
El cliente puede intentar renovarlo mediante un refresh token o pedir al usuario que vuelva a autenticarse.
No conviene ignorar la expiración para evitar interrupciones. Una expiración excesivamente larga aumenta el riesgo si el token se filtra.
Los mensajes de error deberían permitir a la aplicación reaccionar sin revelar detalles que ayuden a un atacante.
Cómo Revocar un JWT
Revocar un JWT significa impedir que siga aceptándose antes de su expiración. Este proceso no es automático en tokens completamente stateless.
Puede utilizarse una lista de identificadores revocados, una versión de sesión, una marca de cambio de credenciales o access tokens muy breves combinados con refresh tokens controlados.
También puede rotarse la clave, aunque esta medida invalida muchos tokens y suele reservarse para incidentes o cambios planificados.
La estrategia debe diseñarse antes de lanzar la aplicación. Añadir revocación después de una incidencia suele exigir cambios importantes.
JWT Stateless
Se dice que JWT permite autenticación stateless cuando el servidor verifica el token sin consultar una sesión central en cada solicitud.
Esto puede facilitar escalado y distribución, pero no significa que el sistema no almacene ningún estado.
Usuarios, permisos, refresh tokens, revocaciones, claves y auditoría siguen necesitando persistencia en muchos proyectos.
La decisión no debería basarse en evitar una consulta por principio. Las sesiones tradicionales pueden ser más simples y seguras para determinadas aplicaciones.
Diferencia Entre JWT y Sesiones
En una sesión tradicional, el cliente conserva un identificador y el servidor almacena el estado asociado. Con JWT, parte de la información puede viajar dentro del token.
- Sesión: revocación sencilla y control central.
- JWT: verificación distribuida y transporte de claims.
JWT puede complicar revocación, rotación y actualización inmediata de permisos. Las sesiones pueden exigir un almacén compartido en arquitecturas distribuidas.
No existe una opción universalmente superior. Una aplicación web monolítica puede funcionar mejor con sesiones y cookies seguras; una API distribuida puede beneficiarse de tokens bien diseñados.
Diferencia Entre JWT y Cookies
JWT es un formato de token. Una cookie es un mecanismo del navegador para almacenar y enviar información.
Un JWT puede guardarse dentro de una cookie. También puede mantenerse en memoria y enviarse en una cabecera.
Las cookies HttpOnly pueden impedir que JavaScript lea el token, reduciendo parte del riesgo de robo mediante XSS. Sin embargo, requieren protección frente a CSRF según la configuración.
Comparar JWT y cookies como alternativas directas mezcla dos niveles diferentes: contenido y transporte.
Guardar JWT en localStorage
LocalStorage permite conservar datos en el navegador y acceder a ellos mediante JavaScript.
Guardar un JWT allí facilita su uso, pero lo expone si un script malicioso consigue ejecutarse en el origen.
Una vulnerabilidad XSS puede leer el token y enviarlo a un atacante.
La decisión debe considerar arquitectura, amenazas, políticas de contenido, duración y alternativas como memoria o cookies HttpOnly.
Guardar JWT en Cookies
Un JWT puede almacenarse en una cookie con atributos de seguridad adecuados.
HttpOnly evita que JavaScript acceda directamente. Secure limita el envío a HTTPS. SameSite ayuda a controlar solicitudes entre sitios.
La aplicación debe considerar CSRF, dominio, ruta, expiración y subdominios.
No basta con “usar cookies”. Una configuración incorrecta puede enviar la credencial a más destinos de los necesarios.
JWT, XSS y CSRF
XSS permite ejecutar scripts maliciosos dentro del contexto de una aplicación. Puede robar tokens accesibles a JavaScript o realizar acciones en nombre del usuario.
CSRF provoca solicitudes no deseadas aprovechando credenciales que el navegador envía automáticamente, como determinadas cookies.
La ubicación del token modifica el perfil de riesgo, pero no elimina la necesidad de prevenir ambas vulnerabilidades.
Se necesitan validación, codificación de salida, políticas de contenido, atributos de cookie, tokens anti-CSRF y una arquitectura adaptada al caso.
Algoritmos de Firma JWT
JWT puede utilizar diferentes algoritmos. Los más habituales pertenecen a familias simétricas y asimétricas.
- HMAC: utiliza un secreto compartido.
- RSA: firma con clave privada y verifica con clave pública.
- ECDSA: utiliza criptografía de curva elíptica.
- EdDSA: utiliza algoritmos modernos basados en curvas específicas.
La elección depende de quién emite, quién verifica, cómo se distribuyen claves y qué soportan las bibliotecas.
JWT con HS256
HS256 utiliza HMAC con SHA-256 y un secreto compartido.
Todos los sistemas capaces de verificar también podrían firmar tokens si conocen el secreto.
Puede ser adecuado cuando emisor y verificador forman parte de un entorno controlado y la gestión del secreto es segura.
La clave necesita suficiente entropía. Una palabra o contraseña fácil de adivinar no es un secreto criptográfico adecuado.
JWT con RS256
RS256 utiliza RSA con SHA-256. El emisor firma con una clave privada y los receptores verifican con la pública.
Esta separación resulta útil cuando muchos servicios necesitan verificar tokens, pero solo uno debe emitirlos.
La clave privada debe permanecer protegida. Las públicas pueden distribuirse mediante mecanismos controlados.
También se necesita rotación, identificadores de clave y gestión de versiones.
Diferencia Entre HS256 y RS256
HS256 utiliza un secreto compartido. RS256 utiliza un par de claves.
Con HS256, cualquier verificador que conozca el secreto puede crear firmas válidas. Con RS256, los verificadores solo necesitan la clave pública.
RS256 facilita escenarios con múltiples servicios y un emisor central. HS256 puede ser más simple en entornos pequeños.
No deberían mezclarse algoritmos sin una configuración estricta. La biblioteca debe aceptar únicamente la familia prevista.
JWT Secret Key
La secret key es la clave utilizada por algoritmos simétricos para firmar y verificar tokens.
Debe generarse mediante una fuente criptográficamente segura, tener suficiente longitud y almacenarse fuera del código fuente.
No conviene reutilizarla entre entornos, aplicaciones o finalidades distintas.
También debe existir un proceso de rotación y respuesta si se sospecha que ha sido expuesta.
JWT Secret Key Generator
Un generador de claves JWT crea valores aleatorios adecuados para algoritmos simétricos.
La herramienta debe utilizar aleatoriedad criptográfica y ejecutarse en un entorno confiable.
No es recomendable copiar una clave de una página desconocida, un tutorial o un repositorio.
Las claves privadas y secretos reales no deberían introducirse en herramientas online ni compartirse mediante canales inseguros.
Rotación de Claves JWT
La rotación sustituye claves antiguas por nuevas sin interrumpir necesariamente todos los tokens activos.
El header puede incluir un identificador que permita seleccionar la clave de verificación adecuada.
Durante una transición, los verificadores pueden aceptar temporalmente varias claves públicas o secretos según una política controlada.
Las claves retiradas deben dejar de aceptarse después del periodo previsto. El proceso necesita documentación, monitorización y capacidad de emergencia.
JWT y OAuth 2.0
OAuth 2.0 es un marco de autorización. JWT es un formato de token. No son equivalentes.
Un sistema OAuth puede emitir access tokens JWT o tokens opacos.
OAuth define flujos, roles y concesiones para obtener acceso. JWT define cómo puede representarse determinada información.
Implementar JWT por cuenta propia no convierte automáticamente una aplicación en compatible con OAuth 2.0.
Diferencia Entre JWT y OAuth 2.0
- JWT: formato para representar claims.
- OAuth 2.0: marco para delegar autorización.
OAuth puede utilizar JWT como access token, como assertion o en otros componentes del flujo.
La elección del formato no sustituye la implementación correcta de clientes, scopes, redirecciones y servidores de autorización.
JWT y OpenID Connect
OpenID Connect añade una capa de identidad sobre OAuth 2.0.
Utiliza un ID token, normalmente en formato JWT, para comunicar información sobre la autenticación del usuario.
El ID token está destinado al cliente que inició el flujo, no debería utilizarse automáticamente como access token ante cualquier API.
El cliente debe validar emisor, audiencia, firma, nonce y expiración según el flujo.
Diferencia Entre ID Token y Access Token
El ID token informa al cliente sobre la autenticación del usuario. El access token concede acceso a una API.
Aunque ambos puedan utilizar JWT, tienen destinatarios y finalidades diferentes.
Enviar un ID token a una API que espera access tokens puede introducir errores de seguridad y validación.
Cada servicio debe comprobar el tipo, la audiencia y el uso previsto.
JWT en APIs REST
En una API REST, JWT suele utilizarse como access token presentado en la cabecera de autorización.
La API valida el token antes de procesar recursos protegidos.
Los endpoints públicos no necesitan token, mientras los privados aplican autenticación y autorización.
La API debe responder de forma coherente ante tokens ausentes, expirados, mal firmados o insuficientes.
JWT en Microservicios
En microservicios, varios componentes pueden verificar tokens emitidos por un proveedor común.
Cada servicio debe validar su audiencia y utilizar solo los claims necesarios.
Pasar el mismo token indiscriminadamente por toda la arquitectura aumenta exposición y mezcla responsabilidades.
En algunos casos conviene intercambiar el token por otro con menor alcance para comunicaciones internas.
JWT en Java
Java dispone de bibliotecas para crear, firmar, analizar y validar JSON Web Tokens.
La implementación debe delegar las operaciones criptográficas en librerías mantenidas y evitar algoritmos personalizados.
El código necesita validar explícitamente algoritmo, firma, emisor, audiencia y fechas.
También conviene separar autenticación, autorización y lógica de negocio para evitar controles dispersos.
JWT con Spring Security
Spring Security permite integrar autenticación y autorización basadas en tokens dentro de aplicaciones Java.
El flujo suele incluir extracción del bearer token, validación, creación del contexto de seguridad y aplicación de reglas de acceso.
En arquitecturas modernas puede utilizarse el soporte de resource server para validar tokens emitidos por un proveedor de identidad.
Implementar filtros personalizados sin necesidad puede aumentar errores. Conviene aprovechar componentes mantenidos y configurarlos de forma explícita.
JWT en Node.js
Node.js dispone de paquetes para firmar y verificar JWT. La aplicación puede utilizarlos en APIs, servidores web y microservicios.
La validación debe ejecutarse en el servidor y limitar algoritmos, emisores y audiencias.
Conviene evitar decodificar el token y copiar sus datos al objeto de usuario sin verificación.
También se necesitan controles de errores, expiración, rotación y almacenamiento seguro de claves.
JWT con npm
El ecosistema npm ofrece bibliotecas de JWT, middleware de autenticación y paquetes para frameworks.
Antes de instalar conviene revisar mantenimiento, vulnerabilidades, versión, documentación y compatibilidad.
Los nombres parecidos pueden pertenecer a paquetes distintos. No debería elegirse únicamente el primer resultado.
Las dependencias deben actualizarse y revisarse como parte del mantenimiento de seguridad.
JWT con Passport
Passport es un middleware de autenticación utilizado en aplicaciones Node.js y dispone de estrategias para bearer tokens JWT.
La estrategia extrae el token, verifica sus condiciones y permite localizar o representar al usuario.
La configuración debe indicar dónde se obtiene el token, qué clave se utiliza y qué algoritmo se acepta.
Passport organiza el flujo, pero no decide por sí solo duración, revocación ni permisos.
JWT en NestJS
NestJS ofrece módulos y patrones para integrar JWT con guards, estrategias y servicios de autenticación.
El guard protege rutas y la estrategia valida el token antes de añadir información al contexto.
La aplicación debe separar access tokens, refresh tokens y credenciales de forma clara.
También conviene utilizar configuración externa y no almacenar secretos directamente en el repositorio.
JWT en Laravel
Laravel puede utilizar paquetes JWT para autenticar APIs, aunque también dispone de alternativas basadas en tokens y sesiones.
La elección debe considerar el tipo de cliente, el ecosistema, la necesidad de revocación y el mantenimiento del paquete.
El middleware puede validar tokens y aplicar permisos a rutas.
No conviene adoptar JWT únicamente porque la aplicación tiene una API. Una solución integrada y mantenida por el framework puede resultar más adecuada.
JWT en PHP
PHP dispone de bibliotecas para firmar y validar tokens con diferentes algoritmos.
La implementación debe utilizar dependencias actualizadas, claves protegidas y validación explícita.
Decodificar un payload sin verificar la firma es un error común en ejemplos simplificados.
También conviene evitar mostrar tokens y secretos en mensajes de error o registros.
JWT en Python
Python cuenta con bibliotecas para trabajar con JSON Web Tokens en frameworks y servicios.
La aplicación debe distinguir entre funciones de decode que verifican y opciones que solo inspeccionan.
Es importante configurar algoritmos aceptados, audiencia, emisor y expiración.
En proyectos con FastAPI, Django o Flask conviene integrar JWT dentro del sistema de seguridad y no dispersar verificaciones manuales por los endpoints.
JWT en FastAPI
FastAPI permite recibir bearer tokens mediante sus utilidades de seguridad y validar credenciales antes de ejecutar dependencias protegidas.
El token puede incluir un identificador del usuario y scopes.
La aplicación debe comprobar que el usuario continúa activo y que los permisos son adecuados.
El ejemplo básico de un tutorial necesita ampliarse con rotación, revocación, protección de secretos y gestión de errores para un entorno real.
JWT en JavaScript del Navegador
JavaScript puede recibir, enviar e inspeccionar tokens dentro de una aplicación web.
El navegador no debería tomar decisiones definitivas de autorización basándose en los claims. El usuario puede modificar la interfaz y las solicitudes.
Los claims pueden utilizarse para adaptar la experiencia, pero el servidor debe verificar cada operación protegida.
La aplicación también necesita controlar dónde conserva el token y reducir el impacto de XSS.
JWT en Angular
Angular puede utilizar interceptores para añadir access tokens a solicitudes destinadas a APIs autorizadas.
El interceptor no debería enviar el token a cualquier dominio. Conviene limitar destinos y condiciones.
Los guards de rutas mejoran la experiencia, pero no sustituyen la autorización del servidor.
La renovación debe evitar múltiples peticiones simultáneas y bucles cuando el refresh token ya no es válido.
JWT en React
React puede integrar JWT mediante servicios de autenticación, contexto, estado y clientes HTTP.
La librería de interfaz no resuelve por sí sola almacenamiento, renovación ni seguridad.
Conviene mantener el access token con la menor exposición posible y centralizar las solicitudes.
La aplicación debe limpiar el estado cuando la sesión termina y reaccionar correctamente ante expiración o revocación.
JWT en Firebase
Firebase utiliza tokens firmados para representar identidades y autorizar acceso a determinados servicios.
Los clientes reciben tokens que los servicios validan según la configuración del proyecto.
También existen custom tokens para iniciar determinados flujos de autenticación.
La aplicación debe seguir las herramientas oficiales y no intentar firmar tokens desde el cliente con credenciales administrativas.
JWT Token Generator
Un generador de JWT crea tokens a partir de un header, un payload y una clave.
Puede resultar útil para pruebas, aprendizaje e integración durante desarrollo.
No conviene utilizar generadores online con claves reales, datos personales o tokens destinados a producción.
En un sistema real, el token debe emitirse dentro de un servicio controlado que aplique autenticación, claims, expiración y auditoría.
Ejemplo de Token JWT
Imaginemos una aplicación de cursos. Después del login, el servidor emite un token con un identificador interno del usuario, el emisor, la audiencia y una expiración breve.
La aplicación utiliza ese access token para consultar el perfil y las clases disponibles.
La API verifica el token y consulta en su sistema si el usuario tiene acceso al curso solicitado.
El token identifica la sesión, pero la autorización final depende del estado actual de la matrícula y no únicamente de un rol guardado durante horas.
Ejemplo de Autenticación con JWT
Una aplicación móvil solicita al usuario su email, contraseña y segundo factor. El servidor valida los datos y emite un access token de corta duración y un refresh token protegido.
La aplicación presenta el access token para consultar información.
Cuando expira, utiliza el refresh token para solicitar uno nuevo. El servidor revisa si la sesión continúa activa y rota el refresh token.
Si el usuario cierra todas las sesiones o se detecta una reutilización, el servidor invalida la familia de refresh tokens.
JWT y Control de Roles
Un JWT puede incluir roles, pero estos pueden quedarse desactualizados hasta la expiración.
Si un administrador pierde permisos, un token de larga duración podría seguir reflejando el rol anterior.
Por eso conviene utilizar tokens breves, versiones de permisos o consultas adicionales para operaciones críticas.
El servidor debe aplicar el principio de mínimo privilegio y no confiar en roles enviados por el cliente sin firma válida.
JWT y Scopes
Los scopes representan capacidades o ámbitos autorizados, especialmente en OAuth.
Un token puede permitir leer perfiles, pero no modificarlos, o acceder únicamente a un conjunto de recursos.
La API debe comprobar los scopes necesarios para cada endpoint.
Conceder scopes demasiado amplios aumenta el impacto de una filtración.
JWT y Multi-Tenant
En aplicaciones multi-tenant, un token puede incluir información sobre la organización o el espacio al que pertenece el usuario.
El servidor no debería confiar únicamente en ese claim para acceder a datos. Debe aplicar filtros y relaciones consistentes en la base de datos.
Una validación incorrecta puede permitir que un usuario consulte información de otra organización.
Las pruebas necesitan cubrir cambios de tenant, roles cruzados y recursos con identificadores manipulados.
JWT y CORS
CORS controla qué orígenes pueden realizar determinadas solicitudes desde un navegador. No es un sistema de autenticación.
Una API puede requerir JWT y además configurar CORS para sus clientes web.
Permitir cualquier origen no hace público automáticamente un endpoint protegido, pero puede ampliar riesgos y exponer respuestas en contextos no deseados.
La configuración debe limitar orígenes, métodos, cabeceras y credenciales según la arquitectura.
JWT y HTTPS
JWT debe transmitirse mediante HTTPS. La firma no protege el token frente a interceptación.
Quien capture un bearer token válido puede reutilizarlo mientras siga activo.
HTTPS protege la comunicación entre cliente y servidor y evita que el token viaje en texto observable por intermediarios.
También deben evitarse registros, URLs y mensajes que expongan el token fuera del canal seguro.
Vulnerabilidades Comunes de JWT
- Aceptar tokens sin firma.
- Confiar en el algoritmo declarado por el token.
- Utilizar secretos débiles.
- No validar emisor o audiencia.
- Ignorar expiración.
- Incluir información sensible.
- Guardar tokens en ubicaciones expuestas.
- No disponer de revocación.
- Registrar tokens completos.
- Enviar tokens mediante URL.
- Aceptar claves obtenidas desde ubicaciones controlables por el atacante.
- Confundir decode con verify.
- Conceder permisos únicamente desde el cliente.
- Utilizar bibliotecas desactualizadas.
Ataque del Algoritmo none en JWT
Algunas implementaciones antiguas o inseguras podían aceptar tokens con un algoritmo que indicaba ausencia de firma.
Un atacante podía modificar el payload y presentar el token sin una protección válida.
Las bibliotecas modernas deberían rechazarlo cuando se espera un token firmado, pero la aplicación debe configurar algoritmos permitidos de forma explícita.
No conviene depender solo de los valores que llegan dentro del header.
Confusión de Algoritmos en JWT
La confusión de algoritmos aparece cuando el verificador interpreta una clave o familia criptográfica de forma distinta a la prevista.
Una configuración flexible puede permitir que un atacante cambie el algoritmo y utilice una clave pública como si fuera un secreto simétrico.
La defensa consiste en fijar el algoritmo esperado, utilizar bibliotecas seguras y separar claramente claves simétricas y asimétricas.
También conviene probar que el sistema rechaza tokens firmados con algoritmos alternativos.
Ataques de Fuerza Bruta Contra JWT
Si un token utiliza HMAC con un secreto débil, un atacante puede intentar adivinarlo fuera del servidor.
Dispone del token, del contenido y de la firma necesarios para comprobar candidatos.
Las claves deben generarse aleatoriamente con suficiente entropía y no basarse en palabras o frases.
Cambiar el algoritmo sin mejorar la gestión de claves no resuelve todos los riesgos.
JWT Hack y Herramientas de Seguridad
Existen herramientas diseñadas para auditar configuraciones JWT, comprobar algoritmos, claves débiles y validaciones.
Deben utilizarse únicamente sobre sistemas propios o con autorización expresa.
En una revisión profesional pueden ayudar a detectar que la API acepta tokens expirados, algoritmos inesperados o claims manipulados.
La herramienta no sustituye una revisión de arquitectura, código, permisos y almacenamiento.
Cómo Proteger una Implementación JWT
- Utilizar HTTPS.
- Seleccionar algoritmos permitidos de forma explícita.
- Generar claves fuertes.
- Separar claves por entorno y finalidad.
- Validar firma, emisor, audiencia y expiración.
- Utilizar access tokens breves.
- Proteger y rotar refresh tokens.
- Diseñar revocación.
- No incluir datos sensibles.
- Evitar tokens en URLs y logs.
- Actualizar bibliotecas.
- Aplicar autorización en el servidor.
- Monitorizar fallos y reutilizaciones.
- Probar casos negativos.
Errores Frecuentes al Implementar JWT
Uno de los errores más comunes es copiar un ejemplo sencillo de autenticación y utilizarlo en producción sin añadir revocación, rotación, permisos y gestión de claves.
Otro problema es convertir JWT en una base de datos portátil. El token termina incluyendo perfiles, preferencias y permisos que quedan desactualizados.
- Elegir JWT sin comparar sesiones.
- Emitir tokens sin expiración.
- Utilizar el mismo secreto en desarrollo y producción.
- Decodificar sin verificar.
- No validar audiencia.
- Guardar contraseñas o datos sensibles.
- Usar access tokens como refresh tokens.
- No invalidar sesiones después de cambios críticos.
- Registrar tokens en analítica.
- Confiar en guards del frontend.
- Aceptar cualquier algoritmo.
- No probar diferencias de reloj.
- No documentar claims.
- Crear tokens demasiado grandes.
- Desarrollar criptografía propia.
Cuándo Utilizar JWT
JWT puede resultar adecuado cuando varios servicios necesitan validar claims de forma distribuida, cuando se integra un proveedor de identidad o cuando una API necesita access tokens estandarizados.
También puede ser útil en aplicaciones móviles, integraciones y arquitecturas donde el receptor no comparte un almacén de sesión con el emisor.
La decisión debe considerar revocación, duración, volumen, sensibilidad y complejidad operativa.
Utilizar JWT porque “es moderno” o porque aparece en muchos tutoriales no constituye un criterio técnico suficiente.
Cuándo No Utilizar JWT
Una aplicación web tradicional con un único servidor puede funcionar mejor mediante sesiones y cookies seguras.
JWT tampoco es adecuado para almacenar información secreta ni para sustituir una base de datos.
Si los permisos cambian continuamente y deben aplicarse de inmediato, un token autónomo de larga duración puede complicar el control.
La solución más simple que cumple los requisitos suele ser preferible a una arquitectura distribuida sin necesidad.
Ventajas de JWT
- Formato compacto y estandarizado.
- Puede verificarse sin consultar una sesión en cada petición.
- Facilita arquitecturas distribuidas.
- Transporta claims estructurados.
- Dispone de bibliotecas en muchos lenguajes.
- Puede utilizar criptografía asimétrica.
- Se integra con OAuth y OpenID Connect.
- Permite limitar audiencia, alcance y duración.
Estas ventajas dependen de una implementación correcta. Un token mal validado puede ser más peligroso que una sesión sencilla.
Desventajas de JWT
- Revocación más compleja.
- Permisos potencialmente desactualizados.
- Riesgo si se roba un bearer token.
- Contenido visible cuando no se cifra.
- Mayor tamaño que un identificador de sesión.
- Gestión de claves y algoritmos.
- Complejidad de refresh tokens.
- Errores frecuentes de almacenamiento.
- Dificultad para invalidar sesiones inmediatamente.
- Falsa sensación de arquitectura stateless.
Cómo Diseñar una Arquitectura JWT
Definir actores y confianza
Hay que identificar quién emite, quién verifica y qué servicios reciben cada token.
Definir los tipos de token
Access, refresh, ID token y tokens de un solo uso necesitan finalidades separadas.
Diseñar claims
Se incluyen únicamente los datos necesarios y se documenta su significado.
Elegir algoritmos y claves
La elección depende del número de verificadores y de la distribución de confianza.
Definir duraciones
La expiración debe equilibrar seguridad, experiencia y capacidad de renovación.
Diseñar revocación
Se establecen cierres de sesión, rotación, listas o versiones de sesión.
Elegir almacenamiento
Se analizan XSS, CSRF, clientes, cookies, memoria y exposición.
Aplicar autorización
Cada servicio valida scopes, roles y estado actual cuando corresponda.
Monitorizar
Se registran fallos de verificación, reutilizaciones y patrones anómalos sin guardar tokens completos.
Probar casos negativos
La aplicación debe rechazar tokens expirados, manipulados, destinados a otra audiencia y firmados con claves incorrectas.
Cómo Depurar Errores JWT
El diagnóstico debe separar formato, firma, claims, tiempo, transporte y permisos.
Primero se comprueba si el token contiene tres bloques y puede decodificarse. Después se revisa algoritmo, identificador de clave, emisor y audiencia.
También hay que comprobar que el servidor utiliza la clave correcta, que los relojes están sincronizados y que el token no ha expirado.
Si la verificación funciona, el problema puede estar en roles, scopes, usuario inactivo o reglas del recurso.
Error Invalid Signature en JWT
Este error indica que la firma calculada por el receptor no coincide con la del token.
Puede deberse a una clave incorrecta, algoritmo distinto, token modificado, codificación o configuración del emisor.
No debería resolverse desactivando la verificación.
Conviene comparar entorno, identificador de clave, algoritmo y fuente de configuración.
Error JWT Expired
El error aparece cuando el momento actual ha superado exp.
La aplicación puede renovar el access token o solicitar una nueva autenticación.
Si ocurre inmediatamente después de emitir, conviene revisar unidades temporales, zona, relojes y tolerancia.
No es recomendable ampliar la duración sin analizar el riesgo.
Error Invalid Audience en JWT
Indica que el token no fue emitido para el servicio que intenta aceptarlo.
Puede deberse a una configuración incorrecta o a que el cliente está enviando un ID token en lugar de un access token.
La solución es emitir y presentar el token adecuado, no eliminar la validación.
La audiencia es una defensa importante frente a reutilización entre servicios.
Error Invalid Issuer en JWT
Significa que el emisor declarado no coincide con los emisores aceptados.
Puede aparecer al mezclar entornos, dominios, tenants o proveedores.
La comparación debe seguir el formato esperado por la biblioteca y la configuración.
No conviene aceptar cualquier emisor dinámicamente a partir del token recibido.
Error Malformed JWT
Un JWT malformed no cumple la estructura esperada. Puede faltar un bloque, contener caracteres incorrectos o llegar con prefijos duplicados.
También puede haberse truncado durante el transporte o copiado con espacios.
La aplicación debería rechazarlo antes de intentar acceder a claims.
Los logs pueden registrar un identificador del incidente, pero no necesitan almacenar el token completo.
Checklist Para Implementar JWT
- Necesidad: JWT aporta una ventaja frente a sesiones.
- Emisor: está claramente identificado.
- Audiencia: cada servicio valida la suya.
- Algoritmo: existe una lista explícita de permitidos.
- Claves: son fuertes, separadas y rotables.
- Claims: contienen solo información necesaria.
- Expiración: está definida y se valida.
- Access token: tiene duración breve.
- Refresh token: está protegido y puede revocarse.
- Almacenamiento: se han evaluado XSS y CSRF.
- HTTPS: es obligatorio.
- Autorización: se ejecuta en el servidor.
- Revocación: existe un mecanismo.
- Logs: no exponen tokens completos.
- Librerías: están mantenidas y actualizadas.
- Pruebas: incluyen tokens manipulados y expirados.
- Monitorización: detecta fallos y reutilizaciones.
- Documentación: explica claims, claves y flujos.
Preguntas Frecuentes Sobre JWT
Qué es JWT
JWT es un formato estandarizado para representar claims dentro de un token compacto que puede firmarse y verificarse.
Qué significa JWT
Significa JSON Web Token.
Para qué sirve JWT
Sirve para transmitir información verificable, autenticar solicitudes, aplicar autorización e integrar APIs y servicios.
Qué es un token JWT
Es una cadena formada normalmente por header, payload y signature.
Cómo funciona JWT
El emisor crea y firma el token; el cliente lo envía; y el receptor verifica la firma, los claims y los permisos.
JWT está cifrado
No necesariamente. Un JWT firmado habitual está codificado y su payload puede leerse.
Qué es JWT decode
Es la operación de mostrar el header y el payload de forma legible sin que eso implique verificar la firma.
Qué diferencia hay entre decode y verify
Decode inspecciona el contenido. Verify comprueba firma y condiciones de validez.
Qué es un claim JWT
Es una declaración incluida en el payload, como emisor, sujeto, audiencia o expiración.
Qué es exp en JWT
Es el claim que establece cuándo expira el token.
Qué es un access token
Es una credencial temporal utilizada para acceder a una API o recurso.
Qué es un refresh token
Es una credencial que permite solicitar nuevos access tokens sin repetir todo el login.
JWT y OAuth son lo mismo
No. JWT es un formato y OAuth 2.0 es un marco de autorización.
JWT y cookies son lo mismo
No. JWT es el contenido o formato del token; una cookie es un mecanismo de almacenamiento y envío del navegador.
Es seguro guardar JWT en localStorage
Lo expone a scripts ejecutados mediante XSS. La decisión debe evaluarse según la arquitectura y las alternativas.
Se puede revocar un JWT
Sí, pero necesita una estrategia como lista de revocación, versión de sesión, access tokens breves o control de refresh tokens.
JWT es stateless
Puede validarse sin una sesión central en cada petición, aunque muchos sistemas siguen almacenando revocaciones, usuarios y refresh tokens.
Qué algoritmo JWT es mejor
Depende de la arquitectura. HMAC utiliza secreto compartido; RSA y otras alternativas asimétricas separan firma y verificación.
Qué es JWT.io
Es una herramienta para inspeccionar la estructura de tokens y consultar información sobre JSON Web Token.
Puede utilizarse JWT en Java, Node.js y Python
Sí. Existen bibliotecas para estos lenguajes y para frameworks como Spring Security, NestJS, Laravel y FastAPI.
JWT sustituye a la base de datos
No. Puede transportar claims, pero los datos, permisos y estados del sistema continúan necesitando almacenamiento y validación.
Qué ocurre cuando un JWT expira
Debe rechazarse. El cliente puede renovarlo mediante un refresh token o iniciar una nueva autenticación.
Se puede modificar un JWT
Puede alterarse el texto, pero la firma dejará de ser válida salvo que el atacante disponga de la clave o exista una vulnerabilidad.
JWT sirve para cualquier aplicación
No. En aplicaciones sencillas, una sesión tradicional puede ofrecer menos complejidad y mejor control de revocación.
Conclusión Sobre Qué Es JWT
JWT es un formato para representar y transmitir declaraciones mediante un token compacto. Su estructura habitual contiene header, payload y signature, y permite comprobar si la información ha sido modificada.
Se utiliza en autenticación, autorización, APIs, microservicios y sistemas de identidad. Sin embargo, no cifra automáticamente el contenido, no evita el robo de tokens y no resuelve por sí solo la gestión de sesiones.
Una implementación segura necesita validar firma, algoritmo, emisor, audiencia, expiración y permisos. También debe proteger claves, limitar la duración, diseñar refresh tokens y disponer de mecanismos de revocación.
En proyectos profesionales recomendamos elegir JWT solo cuando aporta una ventaja clara frente a una sesión convencional. La calidad no depende de generar una cadena válida, sino de diseñar correctamente todo el ciclo: emisión, transporte, almacenamiento, verificación, renovación, revocación y monitorización.