¿Qué es un JWT? Guía práctica sobre claims de tokens, confianza y validación
Privacidad, seguridad e identidad
JWT son las siglas de JSON Web Token. Es un formato de token compacto que se utiliza para transmitir claims entre partes, habitualmente en APIs, OAuth y OpenID Connect. Un JWT puede firmarse para que el destinatario pueda comprobar que proviene de un emisor de confianza y no ha sido alterado; también puede cifrarse cuando se requiere confidencialidad. En la práctica, los JWT suelen aparecer como tokens de acceso o tokens de identidad. Sin embargo, un JWT no es automáticamente seguro por el hecho de ser un token. La seguridad real depende de la validación, los algoritmos de firma, las comprobaciones de emisor y audiencia, la caducidad, la seguridad del transporte, el almacenamiento seguro y la gestión de claves.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Piense en un JWT como un contenedor compacto de declaraciones sobre un sujeto. Esas declaraciones se denominan claims. Entre los ejemplos más habituales figuran quién emitió el token, sobre quién trata, para quién está destinado y cuándo caduca. Dado que el formato es compacto y seguro para URLs, resulta útil en cabeceras HTTP e intercambios de API donde los sistemas necesitan una forma ligera de transportar información de identidad o autorización.
Esa misma comodidad es lo que hace que los JWT sean fáciles de malinterpretar. Un JWT firmado no es secreto. Si alguien puede verlo, generalmente puede leer sus claims aunque no pueda alterarlos con éxito. La firma protege la integridad y el origen, no la confidencialidad. Si se necesita ocultar el contenido, el token debe cifrarse o el diseño debe mantener la información sensible fuera del token por completo.
Esta distinción importa a los responsables porque los JWT suelen circular por sistemas en los que la gente no suele pensar demasiado: pasarelas de API, almacenamiento del navegador, proxies inversos, aplicaciones móviles, registros de actividad, herramientas de desarrollo e integraciones de terceros. Cuando los equipos dicen "es seguro porque es un JWT", la respuesta adecuada es plantear una pregunta diferente: ¿seguro en qué sentido? ¿Firmado? ¿Cifrado? ¿Vinculado al emisor correcto? ¿Destinado a esta audiencia? ¿De corta duración? ¿Protegido en tránsito? ¿Almacenado de forma segura? Esos detalles determinan si el token es fiable o simplemente conveniente.
Por qué es importante
Los JWT son importantes porque se sitúan en el centro de muchos patrones de acceso modernos sin que los responsables de la toma de decisiones siempre los vean. Si su organización utiliza SSO, integraciones de API, un proveedor de identidad, autenticación entre servicios, pasarelas de API o herramientas de datos conectadas a IA, es muy probable que los JWT aparezcan en algún punto del flujo. Los responsables puede que nunca decodifiquen uno manualmente, pero aun así necesitan entender las preguntas que determinan si un sistema basado en JWT es seguro o no.
El atractivo es evidente. Un JWT puede transportar la información que un servicio necesita sin requerir una consulta centralizada para cada solicitud. Eso puede hacer que los sistemas sean más rápidos y fáciles de escalar. Es especialmente habitual cuando un servidor de autorización o proveedor de identidad emite un token y muchos servicios posteriores necesitan evaluarlo. Un servicio puede inspeccionar un token firmado, confirmar la firma y la clave, comprobar el emisor, confirmar que es la audiencia prevista, aplicar la caducidad y proceder.
El riesgo es igualmente práctico. Dado que los JWT son fáciles de transmitir, los equipos se ven tentados a tratarlos como de confianza por defecto. Los claims sensibles se empaquetan en payloads legibles. Las ventanas de caducidad se vuelven demasiado largas. Las APIs aceptan tokens destinados a otros servicios. Las claves antiguas permanecen activas. Los sistemas de registro capturan tokens que nunca debieron quedar expuestos. Los desarrolladores decodifican un token con éxito y asumen que eso equivale a haberlo validado.
Esto también importa en las integraciones habilitadas con IA. Si un asistente, ejecutor de herramientas o servicio de flujo de trabajo interno recibe un JWT y lo utiliza para llamar a APIs o recuperar contenido interno, una validación débil del token puede convertirse en una vía de acceso amplio a recursos internos. La organización no necesita que todos se conviertan en especialistas en criptografía. Sí necesita que todos los que aprueban estos sistemas entiendan que los tokens son tan fiables como las reglas que los rodean.
Cómo funciona
Un JWT suele tener tres partes separadas por puntos: una cabecera, un payload y una firma. La cabecera indica cosas como el tipo de token y el algoritmo. El payload contiene los claims. La firma, cuando está presente, permite al destinatario verificar que el token proviene realmente del emisor esperado y no fue modificado en el camino.
Varios claims aparecen de forma recurrente. El claim de emisor identifica quién emitió el token. El de sujeto indica sobre quién trata el token. El de audiencia indica qué parte dependiente o servicio debe aceptarlo. El claim de caducidad indica cuándo debe dejar de procesarse. Otros claims basados en tiempo pueden indicar cuándo se emitió el token o cuándo debe comenzar a ser válido.
Los JWT firmados y los cifrados son herramientas distintas. Un JWT firmado es útil cuando el destinatario necesita confiar en la integridad y el origen. Un JWT cifrado añade confidencialidad para que los claims no sean visibles para observadores externos. Muchos equipos solo utilizan JWT firmados y asumen erróneamente que nadie puede leerlos. Por eso suele ser más seguro evitar incluir secretos, datos personales innecesarios o información sensible para el negocio en el payload, salvo que exista una razón clara para ello.
La validación es donde se realiza el trabajo real. El destinatario debe verificar la operación criptográfica, asegurarse de que el algoritmo es uno que acepta explícitamente, vincular las claves al emisor correcto, aplicar la caducidad y comprobar que la audiencia incluye el servicio actual. Si gestiona distintos tipos de tokens, también debe aplicar reglas de validación diferentes para que un token de identidad no pueda confundirse con un token de acceso a API solo porque ambos sean JWT.
En OAuth y OpenID Connect, los JWT suelen aparecer como tokens de identidad y a veces como tokens de acceso. En arquitecturas internas también pueden utilizarse entre servicios. Eso no significa que todos los tokens de todos los sistemas sean JWT. Algunos tokens de acceso son intencionalmente opacos y requieren validación mediante consulta. Eso suele ser una decisión de diseño, no una deficiencia.
Ejemplos
Un ejemplo sencillo es una pasarela de API frente a servicios internos. La capa de identidad emite un token de acceso JWT tras el inicio de sesión del usuario. La pasarela comprueba la firma, el emisor, la audiencia y la caducidad antes de reenviar la solicitud. Los servicios posteriores solo reciben solicitudes que ya superaron las comprobaciones de la puerta de entrada. Eso puede ser eficiente y limpio, siempre que las reglas de validación de la pasarela sean realmente estrictas.
Un segundo ejemplo es el SSO y OpenID Connect. Una aplicación empresarial utiliza el proveedor de identidad corporativo para el inicio de sesión y recibe un token de identidad en formato JWT. La aplicación puede usar los claims de ese token de identidad para establecer quién es el usuario. Los problemas comienzan cuando los equipos presentan ese mismo token a una API que esperaba una audiencia o tipo de token diferente. Esta es una forma de confusión de tokens: el token puede ser perfectamente válido, simplemente no lo es para este propósito.
Un tercer ejemplo es la comunicación entre servicios. Un servicio de procesamiento de datos llama a otra API interna usando JWT de corta duración emitidos por una plataforma central. Eso puede funcionar bien porque el servicio receptor puede verificar el token sin almacenar estado de sesión. Pero si esos tokens son de larga duración, se almacenan en registros o se crean con reglas de audiencia amplias, la supuesta comodidad distribuye el riesgo por toda la infraestructura.
Un cuarto ejemplo es una integración de IA. Un asistente interno llama a una API de documentos usando un token de acceso JWT procedente de la plataforma de identidad. Si al asistente se le proporciona un token con acceso de lectura a un amplio corpus interno y ese token es aceptado por varios servicios sin comprobaciones estrictas de audiencia, el asistente puede acceder a más información de la prevista. El formato del token en sí no es el problema. La validación laxa y el alcance amplio sí lo son.
También existe un antipatrón habitual en la capa del navegador. Un equipo almacena JWT en almacenamiento del navegador de fácil acceso, incluye demasiados datos del usuario en el payload y deja la caducidad larga para reducir las solicitudes de inicio de sesión. Eso puede parecer cómodo para el usuario, pero amplía el radio de impacto si un token es robado mediante compromiso del navegador, XSS o registros descuidados.
Malentendidos frecuentes
El mayor malentendido es que "JWT" significa "token seguro". JWT es un formato, no una garantía. El token puede estar firmado con solidez, firmado débilmente, cifrado correctamente, ser legible por diseño, tener larga duración, haber caducado, estar destinado a otro servicio o ser aceptado por un validador mal escrito. La etiqueta por sí sola dice muy poco.
Otro malentendido es que si se puede decodificar un JWT, se ha validado. Decodificar solo revela los claims. No prueba que la firma sea válida, que el emisor sea de confianza ni que la audiencia sea correcta.
Los equipos también confunden firmado con cifrado. Un token firmado protege contra modificaciones no detectadas, pero a menos que también esté cifrado, los claims son generalmente visibles para quien vea el token. Por eso incluir datos sensibles en el payload de los JWT suele ser un error de diseño.
Un cuarto malentendido es que cualquier servicio del mismo entorno debería aceptar un JWT. El claim de audiencia existe precisamente para evitar ese tipo de sustitución. Un token destinado a una parte dependiente no debería convertirse en un pase universal.
Por último, algunas personas creen que los JWT hacen irrelevante la revocación porque existe la caducidad. La caducidad ayuda, pero si los tokens son de larga duración, se rotan mal o están respaldados por claves obsoletas, la organización puede seguir teniendo dificultades para contener el uso indebido con rapidez.
Riesgos y límites
El manejo débil de firmas sigue siendo el fallo clásico de los JWT. Algunos ataques históricos se basaban en que bibliotecas o aplicaciones aceptaban el algoritmo incorrecto, aceptaban tokens sin firmar o confundían las rutas de verificación simétrica y asimétrica. La lección práctica es sencilla: las aplicaciones deben permitir explícitamente solo los algoritmos esperados y rechazar cualquier otro.
La validación del emisor y la audiencia es igualmente importante. Si un receptor no vincula las claves al emisor esperado, o si acepta tokens sin confirmar que es la audiencia prevista, un token emitido en otro contexto puede reproducirse o sustituirse en el contexto equivocado. Eso no es un caso extremo. Es un error de implementación recurrente.
La duración del token es otro riesgo para el negocio. Los tokens de larga duración son atractivos por su usabilidad y para el procesamiento en segundo plano, pero aumentan el valor del robo. Si un token puede reproducirse horas o días después, un pequeño incidente de filtración se convierte en un problema de acceso duradero. Una duración más corta, una gestión cuidadosa de la renovación y una rotación ágil de claves reducen esa exposición.
Los payloads legibles crean un riesgo más silencioso. Dado que los JWT firmados no son secretos por defecto, los equipos deben evitar incluir datos personales sensibles, secretos, notas internas u otro material en los claims, salvo que exista una razón clara y justificada. Si el payload es visible en registros, herramientas del navegador o trazas de soporte, la organización puede exponer información incluso cuando la firma es perfecta.
La confusión entre tokens es otro límite que conviene nombrar con claridad. Una misma empresa puede emitir varios tipos de JWT para distintos usos. Si las reglas de validación no son mutuamente excluyentes, un token creado para el inicio de sesión o para un servicio puede usarse indebidamente en otro lugar. En lenguaje claro: no se debe aceptar "cualquier JWT válido"; solo se debe aceptar el tipo exacto de JWT que el servicio espera.
Los JWT también dependen del transporte y el almacenamiento. Un token bien firmado puede ser robado si se envía por un transporte débil o se almacena de forma descuidada. Para las organizaciones del Reino Unido que gestionan datos personales, esto significa que el diseño de los JWT debe considerarse junto con el transporte seguro, el almacenamiento, la disciplina en los registros y la gobernanza de accesos, y no como una solución autónoma.
Próximos pasos
Pregunte a sus equipos dónde se están utilizando JWT y con qué propósito. El primer objetivo no es un análisis profundo del protocolo, sino una visibilidad básica. ¿Qué sistemas los emiten? ¿Qué servicios los aceptan? ¿Son tokens de identidad, tokens de acceso, tokens de servicio o algo más?
A continuación, exija una respuesta sobre las reglas de validación. Cada servicio receptor debe poder indicar en qué emisor confía, qué audiencia espera, qué algoritmos están permitidos, cómo se aplica la caducidad y cómo se gestiona la rotación de claves. Si la respuesta es "nuestra biblioteca se encarga de eso", la respuesta es incompleta.
Después, revise el diseño del payload. Haga que los equipos justifiquen cualquier dato personal o información empresarial sensible incluida en los claims del token. Si la información no necesita viajar con el token, probablemente no debería hacerlo.
A continuación, examine la duración y el almacenamiento. Pregunte dónde se almacenan los tokens, cuánto tiempo permanecen utilizables, qué ocurre cuando se rotan las claves y cuál es el proceso de respuesta ante incidentes tras una posible filtración. Esto es especialmente importante para sistemas basados en navegador, aplicaciones móviles, pasarelas de API e integraciones de terceros.
Por último, mantenga un lenguaje preciso. Cuando un proveedor diga que utiliza JWT, pregunte si los tokens están firmados o cifrados, si el servicio valida el emisor y la audiencia, y si los tokens son bearer tokens o están vinculados de forma más estricta. Esas preguntas no requieren que los responsables inspeccionen el código. Sí obligan a obtener respuestas más sólidas.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Los JWT solo se usan con OAuth?
No. Los JWT son habituales en OAuth y OpenID Connect, pero también se utilizan en otros diseños de identidad y aplicaciones donde resultan útiles los claims firmados y compactos. Del mismo modo, no todos los tokens OAuth son JWT. Algunos sistemas utilizan tokens opacos en su lugar. Lo importante no es el tipo de token, sino si el servicio dependiente lo valida correctamente y si el formato se adapta al riesgo y la arquitectura.
¿Deberíamos incluir roles y permisos de usuario dentro de un JWT?
En ocasiones, algunos claims limitados son útiles, pero los equipos deben ser cuidadosos. Los roles y permisos dentro de un token pueden quedar obsoletos, compartirse en exceso o ser visibles en lugares que nunca los necesitaron. Si los derechos cambian con frecuencia o los datos son sensibles, un token más ligero combinado con una consulta controlada puede ser un diseño mejor. Los tokens deben transportar solo lo que sea genuinamente necesario para el caso de uso.
¿Cifrar un JWT resuelve todos los riesgos?
No. El cifrado ayuda a proteger la confidencialidad de los claims, pero el destinatario sigue necesitando validar correctamente las operaciones criptográficas, el emisor, la audiencia, la caducidad y el tipo de token. Los tokens cifrados también pueden introducir complejidad en el procesamiento si los equipos asumen que descifrar equivale a confiar. En la práctica, el cifrado aborda una categoría de riesgo. No elimina la necesidad de una validación estricta y una gestión disciplinada de las claves.
Fuentes
RFC 7519 - JSON Web Token (JWT) (IETF). Core JWT definition, compact format and registered claims such as iss, sub, aud and exp.
RFC 8725: JSON Web Token Best Current Practices (IETF). Security best practice, algorithm verification, issuer and audience validation, cross-JWT confusion and weak signature risks.
RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (IETF). Context on JWTs in OAuth 2.0 access-token usage.
Testing JSON Web Tokens (OWASP). Practical review points on exp, iat, nbf, signature verification, none algorithm misuse and secure transport.
NIST IR 8587 initial public draft, Protecting Tokens and Assertions from Forgery, Theft, and Misuse (NIST). Higher-level guidance on protecting tokens and assertions from forgery, theft, misuse and poor lifecycle controls.
API authentication and authorisation (NCSC). Practical context for JWTs as part of modern API and identity patterns.