Cyberpediapor Brain
ESDEENFR

JSON Web Token (JWT)

Un JWT es el justificante que le entrega una aplicación tras iniciar sesión. Qué verifica su firma, las trampas y los gestos que conviene adoptar.

En 30 segundos

Dónde ocurre
Con la plataforma de identidad de Microsoft, que autentica a los usuarios y proporciona tokens de acceso, de actualización y de identidad1.
Qué quiere el atacante
Robar un token válido para actuar con los derechos de su titular, sin conocer la contraseña2.
El reflejo
No enviar ni publicar nunca un token ni una dirección que lo contenga, cerrar la sesión después de usarlo y comunicar cualquier comportamiento anormal.
Si ya ha ocurrido
Cierre la sesión y avise al servicio informático. OWASP recuerda que borrar una cookie no basta: «deleting a cookie alone does not invalidate a stolen copy of the session ID», y es necesaria la invalidación en el servidor6.

De qué se trata

Cuando usted inicia sesión en una aplicación de empresa, esta le entrega un justificante digital que su navegador o su aplicación presenta después en cada solicitud. En Microsoft, ese justificante adopta la forma de un JSON Web Token, o JWT, que contiene «claims», es decir, declaraciones sobre el usuario o la aplicación1.

Un JWT puede decodificarse, por ejemplo con el sitio jwt.ms, y su firma sirve para verificar la autenticidad del token3. Esta ficha presenta los gestos del empleado y los del responsable.

Preguntas directas

¿Qué es un JWT?

Un JWT consta de tres segmentos separados por un punto: la cabecera, el cuerpo y la firma3. El cuerpo contiene los claims. La firma sirve para evaluar la autenticidad del token3.

¿Impide la firma leer el token?

La firma sirve para verificar la autenticidad del token. Microsoft indica que los desarrolladores pueden decodificar un JWT con un sitio como jwt.ms, con fines de validación y depuración3. El token es sensible y supone un riesgo de seguridad si se manipula mal3.

¿Permite realmente un token robado actuar en mi lugar?

Sí. MITRE describe adversarios que utilizan tokens de acceso robados para eludir el proceso habitual de autenticación y acceder a cuentas, información o servicios. Estos tokens se utilizan en lugar de las credenciales de inicio de sesión2.

¿Sigue siendo válido mucho tiempo un token robado?

Depende de su duración. En los tokens de acceso de Microsoft, la duración por defecto es un valor aleatorio entre 60 y 90 minutos, 75 minutos de media3. Los inquilinos sin acceso condicional tienen una duración por defecto de dos horas para clientes como Microsoft Teams y Microsoft 3653. MITRE señala, no obstante, que el adversario a veces puede robar también un token de actualización, que le permite obtener nuevos tokens de acceso sin molestar al usuario4.

1Cómo funciona1 min

El servidor de autorización firma el token con una clave privada y publica la clave pública correspondiente. Para validar un token, la aplicación verifica la firma con esa clave pública1. La cabecera del JWT indica el algoritmo de firma (claim alg) y la clave pública que debe usarse (claim kid)3. Microsoft Entra ID emite tokens firmados con algoritmos asimétricos estándar, como RS2563.

El token de acceso se transmite a una API como token «bearer» en la cabecera Authorization1. Como los tokens son válidos durante un tiempo limitado, el servidor suele proporcionar un par: un token de acceso y un token de actualización, que sirve para renovar el primero cuando se acerca su caducidad1. El token de actualización solo da un nuevo token de acceso si el usuario sigue autorizado1.

En el caso de OpenID Connect, el ID Token es un JWT firmado que permite a una aplicación verificar la identidad del usuario5.

2Lo que usted hace2 min

Como empleado:

  • No envíe nunca un token, ni una dirección web que lo contenga, en un mensaje, un ticket o un foro. Los identificadores de sesión colocados en una dirección pueden acabar en enlaces, registros, el historial del navegador, los marcadores, la cabecera Referer o los motores de búsqueda6.
  • Cierre la sesión cuando termine. Una aplicación debe ofrecer un botón de cierre de sesión visible y accesible, para que el usuario pueda cerrar su sesión en cualquier momento6.
  • No cuente con que cerrar el navegador baste: no permite imponer un cierre de sesión de forma fiable, sobre todo en el móvil6.
  • Comunique cualquier comportamiento anormal (cierres de sesión inesperados, acciones que usted no ha realizado, solicitud de autorizar una aplicación desconocida). MITRE describe atacantes que consiguen que se conceda acceso a una aplicación maliciosa enviando un enlace de suplantación de identidad dirigido4.

Como responsable, lo que debe exigir a los equipos y a los proveedores:

  • La validación de la firma y del emisor por parte de la aplicación que recibe el token, con los valores publicados en el documento de descubrimiento de OpenID3.
  • El control de la audiencia: una API solo debe aceptar los tokens cuyo claim aud le corresponda. Aceptar un token destinado a otro recurso es un ejemplo del problema del «confused deputy»3.
  • Bibliotecas contrastadas en lugar de código propio. Microsoft recomienda sus bibliotecas MSAL, que gestionan la obtención, la actualización y la validación de los tokens1.
  • Duraciones de sesión limitadas. OWASP cita como rangos habituales de tiempo de inactividad de 2 a 5 minutos para las aplicaciones de alto valor y de 15 a 30 minutos para las de bajo riesgo, y pide además un tiempo máximo absoluto, sea cual sea la actividad6.
  • Un almacenamiento prudente en el navegador (véase la sección siguiente).
3Las trampas2 min

MITRE indica que los tokens robados se «used in lieu of login credentials», es decir, en lugar de las credenciales de inicio de sesión2. MITRE señala que las cookies de sesión pueden eludir ciertos protocolos de autenticación multifactor7.

En las fuentes se repiten varios errores de implementación.

  • El almacenamiento en el navegador. OWASP desaconseja guardar tokens de autenticación, identificadores de sesión, JWT o tokens de actualización en localStorage o sessionStorage: esos espacios son accesibles para cualquier JavaScript que se ejecute en el origen, de modo que un solo fallo XSS revela todos los tokens6. OWASP prefiere cookies HttpOnly, Secure y SameSite=Strict, o un modelo de tipo Backend-for-Frontend6.
  • El token en la dirección. Un identificador transmitido por la URL puede filtrarse y facilitar otros ataques, como la fijación de sesión6.
  • Una validación hecha en el lugar equivocado. Según Microsoft, un cliente no debe intentar validar un token de acceso: corresponde a la API hacerlo, y el cliente lo trata como una cadena opaca3.
  • La confianza en el contenido sin verificar la firma. Una aplicación que debe validar un token empieza por verificar la firma y el emisor3.
  • Tokens sustraídos de la infraestructura. En entornos Kubernetes o en cadenas de integración y despliegue continuos, pueden robarse tokens de API si el contenedor o la cadena están comprometidos4.
  • El robo de sesión mediante un script malicioso o un proxy de suplantación de identidad. MITRE cita programas maliciosos que apuntan a las cookies del navegador y herramientas libres como Evilginx2 y Muraena, que recuperan cookies mediante un proxy malicioso7.

Las fuentes citadas aquí no detallan otros errores de diseño citados con frecuencia, como el algoritmo «none», la confusión entre claves o los secretos débiles. Conviene que los equipos de desarrollo comprueben este punto con sus propios referenciales.

Ficha

Identificador
CP-195
Ala
3. Protocolos y defensa
Competencia Brain
Controlar los accesos (control_access)
Reflejo Brain
cr-027
Esquema
G3 · Corte anatómico
Idiomas
de, en, es, fr
Fuentes
7 fuentes verificadas el 3 de noviembre de 2026
Fuentes7 fuentes
  1. Microsoft, «Tokens and claims overview - Microsoft identity platform», 21 de marzo de 2025. https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens (consultado el 3 de noviembre de 2026)
  2. MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1550/001/ (consultado el 3 de noviembre de 2026)
  3. Microsoft, «Access tokens in the Microsoft identity platform - Microsoft identity platform», 14 de mayo de 2025. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (consultado el 3 de noviembre de 2026)
  4. MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1528/ (consultado el 3 de noviembre de 2026)
  5. OWASP, «Authentication - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html (consultado el 3 de noviembre de 2026)
  6. OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultado el 3 de noviembre de 2026)
  7. MITRE ATT&CK, «Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1539/ (consultado el 3 de noviembre de 2026)

Citar este artículo

Brain, «JSON Web Token (JWT)», Cyberpedia, 2026. https://startbrain.io/cyberpedia/es/articles/jwt-json-web-token-firma-trampas/

BibTeX 
@misc{brain_cp195_es_2026,
  author = {Brain},
  title = {JSON Web Token (JWT)},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/es/articles/jwt-json-web-token-firma-trampas/},
  note = {CC BY 4.0}
}
Licencia CC BY 4.0