Tokens de autenticación: tipos, usos y prácticas recomendadas

Los tokens de autenticación verifican la identidad, pero los tokens robados eluden la seguridad. Conozca JWT, OAuth 2.0, SAML y los tokens de hardware, los errores comunes y las estrategias de defensa. Vea cómo SentinelOne detecta ataques basados en identidad en Active Directory y Entra ID.

¿Qué es un token de autenticación?

Imagine esto: inicia sesión en su aplicación empresarial a las 9 a. m. en Nueva York. Treinta minutos después, alguien accede a su cuenta desde Tokio. Su contraseña nunca cambió. Su token de autenticación multifactor (MFA) permaneció en su escritorio. Pero un atacante acaba de entrar por la puerta principal usando un token de autenticación robado.

Los tokens de autenticación son las credenciales digitales que verifican su identidad en todos los sistemas empresariales. Son credenciales criptográficas, por lo que su contraseña nunca viaja con la solicitud. Según la Publicación Especial 800-63B-4 de NIST, estos tokens establecen la base de la garantía de identidad digital en las arquitecturas modernas de ciberseguridad.

El escenario anterior no es hipotético. En 2023, un actor de amenazas extrajo tokens de sesión de archivos de soporte cargados en el sistema de soporte al cliente de Okta y los utilizó para secuestrar las sesiones activas de cinco clientes. No se vulneró ninguna contraseña. No se respondió a ninguna solicitud de MFA. Se presentó un token válido, y el sistema hizo exactamente lo que estaba diseñado para hacer.

Comprender cómo funcionan los tokens, dónde fallan y cómo protegerlos es lo que diferencia una infraestructura de autenticación que resiste de una infraestructura que entrega las llaves a un atacante. Esta página explica los tres aspectos.

Por qué los tokens de autenticación son objetivos de seguridad

Los tokens se sitúan en la intersección entre su seguridad de identidad y la arquitectura de control de acceso. Cuando se autentica en cualquier sistema, no lleva sus credenciales reales en cada solicitud. En su lugar, recibe un token que dice: "esta persona ya demostró quién es".

Robar un token permite a un atacante omitir la autenticación por completo. Falsificar uno le permite suplantar a un usuario legítimo. Manipular la forma en que se valida un token le permite escalar privilegios sin llegar a tener una cuenta autorizada.

El costo de equivocarse en esto está bien documentado. El Informe 2026 sobre el costo de una filtración de datos de IBM sitúa el promedio global de una filtración en 4,99 millones de dólares, un máximo histórico. El Informe 2026 de investigaciones sobre filtraciones de datos (DBIR) de Verizon concluyó que la explotación de vulnerabilidades superó a las credenciales robadas como principal punto de entrada de las filtraciones por primera vez en los 19 años de historia del informe. Las credenciales ocuparon ese lugar hasta este año, y un token robado es una credencial que ya superó la puerta principal.

Para comprender estos riesgos, los equipos de seguridad primero deben reconocer los diferentes tipos de tokens que implementan las organizaciones y cómo cada uno presenta consideraciones de seguridad únicas.

Tipos de tokens de autenticación

Las organizaciones implementan distintos tipos de tokens según sus requisitos de seguridad y casos de uso.

• JSON Web Tokens (JWTs): Tokens autocontenidos que transportan declaraciones codificadas en una estructura de encabezado-carga útil-firma. Los JWTs permiten una verificación sin estado en la que los servidores validan tokens sin consultas a bases de datos, lo que los hace ideales para arquitecturas distribuidas de microservicios.
• OAuth 2.0 Tokens: El marco OAuth utiliza dos tipos de tokens que funcionan juntos. Los tokens de acceso proporcionan credenciales de corta duración para llamadas a API, mientras que los tokens de actualización obtienen nuevos tokens de acceso sin volver a autenticarse. Esta separación limita el daño derivado del robo de tokens.
• Aserciones SAML (Security Assertion Markup Language): Tokens basados en XML intercambiados entre proveedores de identidad y proveedores de servicios para inicio de sesión único empresarial. SAML sigue siendo dominante en entornos empresariales heredados y escenarios de federación B2B.
• Tokens de sesión: Identificadores generados por el servidor que vinculan navegadores con el estado de sesión del lado del servidor. A diferencia de los JWTs sin estado, los tokens de sesión requieren almacenamiento en el servidor, pero ofrecen capacidades de revocación inmediata.
• FIDO2/Hardware Tokens: Autenticadores físicos que utilizan criptografía de clave pública mediante las API de WebAuthn. Estos tokens ofrecen resistencia al phishing mediante vinculación criptográfica al origen, lo que garantiza que las credenciales funcionen solo en sitios legítimos.

Aunque cada tipo de token cumple propósitos distintos, comparten elementos arquitectónicos comunes que determinan su postura de seguridad. Esos componentes son donde comienza el endurecimiento.

Componentes principales de los tokens de autenticación

Los tokens de autenticación contienen elementos específicos que determinan su postura de seguridad y sus capacidades funcionales.

1. Estructura del token: Los JWTs constan de tres secciones: encabezado (especifica el algoritmo de firma como RS256 o ES256), carga útil (contiene declaraciones) y firma (garantiza la integridad criptográfica). Las aserciones SAML utilizan declaraciones con formato XML según las especificaciones de OASIS SAML V2.0.
2. Metadatos del token: Los tokens transportan metadatos dentro de su carga útil. Las marcas de tiempo de expiración (declaración exp) definen ventanas de validez, las declaraciones de emisión (iat) establecen la antigüedad del token, el ID de JWT (jti) proporciona identificadores únicos para el seguimiento de revocación y las restricciones de audiencia (declaración aud) evitan la reutilización del token entre servicios.
3. Entropía de sesión: Los tokens de sesión de aplicaciones web requieren una entropía mínima generada mediante generadores de números pseudoaleatorios criptográficamente seguros (CSPRNG).
4. Criptografía de tokens de hardware: Los tokens FIDO2 combinan las API del navegador WebAuthn con Client to Authenticator Protocol (CTAP). Las claves privadas nunca salen del elemento seguro, y la vinculación criptográfica al origen garantiza que las credenciales funcionen solo en sitios web legítimos.

Estos componentes se combinan en flujos de trabajo, y el flujo de trabajo es donde la seguridad del token se gana o se pierde. Las secciones siguientes describen cada flujo, incluida la forma en que los tokens interactúan con la autenticación multifactor.

Cómo funcionan los tokens de autenticación

Los tokens de autenticación siguen flujos de trabajo distintos según el tipo y el contexto de implementación.

• Flujo de autenticación JWT: Usted envía credenciales al servidor de autenticación. El servidor valida las credenciales, genera y firma criptográficamente un JWT con declaraciones de expiración, audiencia y emisor, y lo devuelve a su cliente. En las solicitudes posteriores, incluye el JWT en el encabezado Authorization. El servidor de recursos valida la firma y verifica las declaraciones antes de conceder acceso.
• OAuth 2.0 Flujo de código de autorización: Usted solicita acceso a un recurso protegido. Después de la autenticación y el consentimiento, el servidor emite un código de autorización que su aplicación intercambia por tokens de acceso y de actualización. Usted utiliza tokens de acceso de corta duración para llamadas a API e intercambia tokens de actualización por nuevos tokens de acceso cuando es necesario.
• SSO de navegador web SAML: Usted intenta acceder a una aplicación de proveedor de servicios, que lo redirige al proveedor de identidad. Después de autenticarse, el IdP genera una aserción SAML firmada y la publica en el proveedor de servicios, estableciendo su sesión autenticada y habilitando el inicio de sesión único en múltiples aplicaciones.
• Actualización y rotación de tokens: Los tokens de acceso de corta duración expiran con frecuencia, lo que requiere mecanismos de actualización. La rotación de tokens genera un nuevo token de actualización cada vez que se usa uno, lo que evita ataques de repetición. Si alguien reutiliza un token de actualización, el sistema detecta un posible compromiso y puede revocar toda la familia de tokens.
• Autenticación con token de hardware: Usted registra su autenticador FIDO2 generando un par de claves en el elemento seguro del dispositivo. Durante la autenticación, el servicio envía un desafío criptográfico que su autenticador firma con la clave privada. El servicio verifica la firma utilizando la clave pública registrada.

Cuando se implementan correctamente, estos flujos de trabajo justifican su complejidad. Aquí es donde eso da resultado.

Casos de uso de los tokens de autenticación

Los tokens de autenticación abordan requisitos específicos de seguridad y operación en entornos empresariales.

1. Inicio de sesión único empresarial: Las aserciones SAML permiten que los empleados se autentiquen una vez y accedan a decenas de aplicaciones sin inicios de sesión repetidos. Los proveedores de identidad como Okta, Azure AD y Ping Federation emiten tokens en los que confían los proveedores de servicios, lo que reduce la fatiga de contraseñas y centraliza la gobernanza del acceso.
2. Seguridad de API y microservicios: Los tokens de acceso OAuth 2.0 protegen la comunicación entre servicios en arquitecturas distribuidas. Cada microservicio valida de forma independiente los tokens entrantes, lo que permite escalabilidad sin estado sin almacenes de sesión compartidos.
3. Autorización de terceros: OAuth 2.0 habilita escenarios de "Iniciar sesión con Google" en los que los usuarios autorizan a las aplicaciones a acceder a sus datos sin compartir contraseñas. El servidor de autorización emite tokens con alcance limitado que restringen a qué pueden acceder las aplicaciones.
4. Sesiones de aplicaciones móviles: Los JWTs proporcionan autenticación persistente para aplicaciones móviles. Los tokens almacenados en iOS Keychain o Android KeyStore sobreviven a los reinicios de la aplicación, proporcionando experiencias de usuario fluidas mientras mantienen la seguridad mediante almacenamiento seguro específico de la plataforma.
5. Autenticación máquina a máquina: Los sistemas automatizados y los dispositivos IoT utilizan concesiones de credenciales de cliente para obtener tokens para acceso a API. Estos tokens autentican trabajos programados, sistemas de monitoreo y comunicaciones de dispositivos sin interacción humana.

El patrón se mantiene en todos ellos. Los tokens sustituyen la transmisión repetida de credenciales por una declaración que el sistema receptor puede verificar por sí mismo.

Principales beneficios de los tokens de autenticación

La autenticación basada en tokens supera a la gestión de sesiones tradicional en cuatro aspectos:

1. Escalabilidad sin estado: Los sistemas basados en tokens eliminan los requisitos de almacenamiento de sesiones del lado del servidor, lo que habilita arquitecturas de microservicios en las que los servicios individuales verifican credenciales de forma independiente sin estado compartido.
2. Inicio de sesión único entre dominios: Las aserciones SAML 2.0 y OpenID Connect habilitan el inicio de sesión único. Los usuarios se autentican una vez y acceden a múltiples aplicaciones sin inicios de sesión repetidos, centralizando la gobernanza de la autenticación.
3. Seguridad de API y Zero Trust: La autenticación entre servicios mediante credenciales de cliente OAuth 2.0 y JWTs firmados evita que servicios no autorizados suplanten a servicios de confianza, algo esencial para las arquitecturas zero-trust.
4. Superficie de ataque reducida: La implementación basada en estándares protege contra ataques específicos. Las cookies HttpOnly evitan el acceso de JavaScript. Los atributos SameSite detienen los ataques Cross-Site Request Forgery (CSRF). Los tokens FIDO2 logran resistencia al phishing mediante vinculación criptográfica al origen.

Sin embargo, estos beneficios implican compensaciones. Las mismas decisiones arquitectónicas que permiten escalabilidad y flexibilidad también introducen desafíos que los equipos de seguridad deben abordar.

Desafíos y limitaciones de los tokens de autenticación

La autenticación basada en tokens introduce desafíos operativos y de seguridad específicos que requieren una planificación arquitectónica cuidadosa.

1. Complejidad de la revocación de tokens: La naturaleza sin estado que proporciona beneficios de escalabilidad crea desafíos para la terminación inmediata del acceso. Los tokens sin estado siguen siendo válidos hasta su expiración, lo que requiere ya sea tiempos de vida cortos que aumentan la sobrecarga de actualización, infraestructura de listas negras de tokens que anula los beneficios sin estado, o la aceptación de ventanas de latencia de revocación.
2. Compensaciones en la gestión del tiempo de vida de los tokens: Los tiempos de vida cortos de los tokens de acceso limitan el daño potencial en caso de compromiso, pero requieren intercambios constantes de tokens de actualización. Los tiempos de vida largos mejoran la experiencia del usuario, pero crean ventanas de exposición mayores si los tokens son robados.
3. Almacenamiento seguro de tokens en distintas plataformas: Cualquier script que se ejecute en la página puede leer localStorage y sessionStorage, por lo que una sola vulnerabilidad de Cross-Site Scripting (XSS) convierte cualquiera de los dos en una lista de tokens válidos. El enfoque híbrido ampliamente adoptado almacena los tokens de actualización en cookies HttpOnly, mantiene los tokens de acceso en memoria y aplica comprobaciones CSRF en el endpoint de actualización. Un token de acceso en memoria sigue estando expuesto al volcado de memoria en un host comprometido, que es para lo que sirve la seguridad de endpoints. Las aplicaciones móviles necesitan almacenamiento específico de la plataforma: iOS Keychain almacena los tokens directamente, mientras que Android los cifra con una clave almacenada en Android Keystore. La comunicación de servidor a servidor debe pertenecer a un sistema de gestión de secretos como HashiCorp Vault o AWS Secrets Manager.
4. Rotación de claves y gestión criptográfica: La rotación de claves en entornos de producción introduce complejidad de coordinación. Las organizaciones deben mantener múltiples claves de firma válidas durante las ventanas de rotación, coordinar la rotación entre servicios distribuidos y gestionar correctamente la validación del identificador de clave (kid).

Estos desafíos de implementación crean vulnerabilidades específicas que los atacantes explotan activamente en entornos empresariales.

Errores comunes de implementación de tokens de autenticación

La mayoría de las filtraciones relacionadas con tokens de autenticación se deben a errores de implementación más que a fallos criptográficos. Comprender estos errores comunes ayuda a los equipos de seguridad a priorizar sus esfuerzos de endurecimiento.

• Almacenamiento inseguro del lado del cliente: Almacenar tokens de autenticación en localStorage o sessionStorage del navegador representa uno de los errores de implementación más frecuentes. Cualquier código JavaScript que se ejecute dentro del contexto de la página puede acceder directamente y exfiltrar tokens de autenticación, haciéndolos inmediatamente vulnerables a ataques XSS.
• Fallos en la validación de firmas: No validar correctamente las firmas JWT crea vulnerabilidades explotables de omisión de autenticación. Los ataques de confusión de algoritmos manipulan el encabezado del algoritmo de RS256 (asimétrico) a HS256 (simétrico), y luego firman tokens utilizando la clave pública como secreto HMAC. Los sistemas vulnerables aceptan estos tokens modificados, lo que permite la escalada de privilegios. Esta vulnerabilidad fue documentada en CVE-2024-54150 con una calificación de severidad CVSS 9.1 CRITICAL. Algunas implementaciones aceptan tokens que especifican "alg: none", procesando efectivamente tokens sin firma como válidos.
• Tiempos de vida excesivos de los tokens: Configurar tiempos de vida demasiado largos para los tokens crea riesgos de seguridad persistentes. Los tokens de larga duración proporcionan a los atacantes ventanas de oportunidad extendidas. Una vez comprometidos mediante XSS o ataques man-in-the-middle, los tokens con tiempos de vida excesivos permiten acceso no autorizado durante días o semanas en lugar de minutos.
• Ausencia de mecanismos de revocación de tokens: La ausencia de capacidades de revocación de tokens representa una brecha arquitectónica significativa. El compromiso de Primary Refresh Tokens (PRTs) utilizados en implementaciones de SSO como Azure AD resulta especialmente problemático. Sin mecanismos de revocación, las organizaciones no pueden terminar sesiones comprometidas en tiempo real, lo que obliga a depender de la expiración natural del token.
• Gestión insegura de claves: Los fallos en la gestión de claves crean vulnerabilidades sistémicas. Las vulnerabilidades de SQL injection en mecanismos de recuperación de claves pueden exponer claves de firma cuando las aplicaciones utilizan consultas SQL vulnerables para recuperar claves JWT mediante el parámetro kid. Almacenar información sensible en las cargas útiles de JWT crea una exposición de datos innecesaria porque las declaraciones JWT solo están codificadas en base64 (no cifradas), lo que las hace trivialmente legibles para cualquiera con acceso al token.

Estos fallos tienen nombres y fechas. En abril de 2022, un atacante utilizó tokens OAuth robados de Heroku y Travis CI para descargar repositorios privados de decenas de organizaciones, incluido npm. El robo del token de sesión de Okta descrito al inicio de esta página funcionó de la misma manera: tokens válidos, presentados por la parte equivocada, aceptados sin cuestionamiento.

Cada uno de estos fallos se puede prevenir, y los controles ya están documentados. La defensa en profundidad basada en estándares establecidos cierra las brechas con las que cuentan los atacantes.

Prácticas recomendadas para tokens de autenticación

Proteger los tokens de autenticación requiere implementar estrategias de defensa en profundidad basadas en estándares de seguridad autorizados como NIST SP 800-63B-4, OWASP y especificaciones de IETF.

• Implementar cookies HttpOnly y Secure: Combine tokens de actualización almacenados en cookies HttpOnly con tokens de acceso mantenidos en memoria. Configure la marca HttpOnly para impedir el acceso de JavaScript al contenido de las cookies. Configure la marca Secure para garantizar la transmisión solo a través de conexiones HTTPS. Implemente el atributo SameSite para protección CSRF.
• Implementar tokens de acceso de corta duración con rotación: Configure los tiempos de vida de los tokens de acceso según la tolerancia al riesgo. La rotación de tokens genera un nuevo token de actualización cada vez que se usa uno, lo que evita ataques de repetición. Realice el seguimiento de todos los tokens de actualización emitidos mediante sus declaraciones jti e invalide los tokens anteriores inmediatamente después de una rotación exitosa.
• Aplicar validación estricta de firmas: Rechace explícitamente los tokens con "alg: none" especificado en el encabezado. Valide que los algoritmos de firma coincidan con los tipos esperados, evitando ataques de confusión RSA/HMAC. Utilice consultas parametrizadas para la recuperación de claves a fin de evitar SQL injection.
• Implementar token binding: Configure políticas de acceso condicional para aplicar token binding, garantizando que los tokens no puedan funcionar fuera de sus dispositivos emitidos originalmente mediante integración con Trusted Platform Module (TPM) o Secure Enclave.
• Implementar infraestructura de revocación: Cree seguimiento de familias de tokens respaldado por base de datos utilizando declaraciones jti. Cree interfaces administrativas para la revocación de sesiones e implemente la funcionalidad "cerrar sesión en todas partes" que permita a los usuarios revocar todas las sesiones cuando sospechen un compromiso.

Incluso con estas prácticas recomendadas implementadas, los atacantes sofisticados siguen encontrando formas de comprometer tokens. Cuando la prevención no resiste, lo que importa es la rapidez con la que detecta el uso indebido y la rapidez con la que puede actuar.

Cómo SentinelOne detecta ataques basados en identidad

Singularity™ Platform ofrece detección y respuesta autónomas en sus endpoints, cargas de trabajo en la nube e infraestructura de identidad. En las Evaluaciones MITRE ATT&CK 2024: Enterprise, SentinelOne registró un 100 % de detección con un 88 % menos de alertas que la mediana de todos los proveedores evaluados, lo que marca la diferencia entre una cola de alertas que sus analistas pueden gestionar y una que abandonan. Purple AI™ acelera la propia investigación. Los analistas preguntan en lenguaje natural y reciben resúmenes contextuales de alertas, con hasta un 80 % más de rapidez en la búsqueda de amenazas.

Singularity Identity defiende Active Directory y Entra ID frente a amenazas de identidad. Sus detecciones se activan ante los ataques de credenciales que apuntan directamente a esos entornos, incluido el uso de tickets Kerberos robados y falsificados para movimiento lateral y escalada de privilegios. La tecnología Storyline™ reconstruye el ataque a medida que se desarrolla y correlaciona eventos de autenticación con el comportamiento del endpoint. Usted ve la cadena completa, no una sola alerta. Cuando se activa una detección, la respuesta autónoma contiene la amenaza, aísla el host y revierte el daño con rollback en 1-Click antes de que el ransomware complete el cifrado. 

Solicite una demostración de SentinelOne para ver la detección basada en identidad funcionando en su propio entorno.

Realizar el recorrido

Obtenga protección de identidad en tiempo real y visibilidad de extremo a extremo en entornos híbridos para detectar exposiciones, detener el abuso de credenciales y reducir el riesgo de identidad.

Conclusiones clave

¿Ese escenario de ataque desde Tokio del inicio? Ocurre cuando un token robado omite la autenticación sin tocar nunca una contraseña ni una solicitud de MFA. Los tokens mal configurados crean una exposición real, y los tokens siguen siendo esenciales de todos modos. Cada tipo tiene una función: JWTs para microservicios sin estado, OAuth 2.0 para autorización de API, SAML para SSO empresarial y FIDO2 para autenticación resistente al phishing. Cada uno de ellos se convierte en un vector de ataque cuando se implementa sin cuidado.

La lista de correcciones es corta. Almacene los tokens de actualización en cookies HttpOnly, mantenga los tokens de acceso en memoria, valide las firmas estrictamente y rote en cada actualización. La mayoría de los fallos de esta página son uno de esos puntos sin implementar, más dos que es más fácil posponer que construir: infraestructura de revocación y gestión de claves.

Añada XDR y detección y respuesta ante amenazas de identidad (ITDR) para que un token en las manos equivocadas aparezca como una detección en lugar de un hallazgo de auditoría seis meses después. CVE-2024-54150 y los ocho grupos patrocinados por estados nacionales rastreados en la actualización de octubre de 2024 de MITRE ATT&CK muestran que la explotación de tokens es activa y actual. Los controles que la detienen ya existen, y están a su disposición para implementarlos.

Preguntas frecuentes

¿Qué es un token de autenticación?

Un token de autenticación es una credencial criptográfica que verifica su identidad ante los sistemas empresariales sin requerir la transmisión repetida de su nombre de usuario y contraseña. Cuando inicia sesión en una aplicación, el servidor emite un token como prueba de una autenticación exitosa. 

Su dispositivo presenta este token con cada solicitud posterior, lo que permite a los servidores verificar su identidad sin un segundo inicio de sesión. Los formatos comunes incluyen JSON Web Tokens (JWTs), tokens OAuth 2.0, aserciones SAML y tokens FIDO2.

¿Cuál es la diferencia entre los tokens de acceso y los tokens de actualización?

Los tokens de acceso proporcionan credenciales de corta duración para acceder a recursos protegidos, y normalmente expiran en cuestión de minutos según las recomendaciones de NIST. Los tokens de actualización permiten obtener nuevos tokens de acceso cuando los tokens actuales expiran sin requerir autenticación repetida, y normalmente duran de días a semanas. 

Este enfoque de doble token equilibra la seguridad mediante ciclos de vida cortos de los tokens de acceso con la experiencia del usuario. La rotación de tokens genera un nuevo token de actualización con cada uso, invalidando el anterior para evitar ataques de repetición.

¿Cómo roban los atacantes los tokens de autenticación?

Los atacantes roban tokens mediante ataques XSS que extraen tokens de localStorage, ataques de intermediario que interceptan la transmisión, volcado de memoria en endpoints comprometidos, explotación de pipelines de CI/CD y secuestro de sesión mediante CSRF. 

Ocho grupos de actores estatales, incluidos APT28, APT29, APT41, Kimsuky, MuddyWater, OilRig, Sandworm Team y Turla, actualizaron las capacidades de ataque de tokens en 2024. La protección requiere cookies HttpOnly, transmisión segura a través de HTTPS, vinculación de tokens a dispositivos y monitoreo del comportamiento que detecte  patrones de uso anómalos.

¿Cómo debe almacenar los tokens de autenticación en aplicaciones web?

Almacene los tokens de actualización en cookies HttpOnly, Secure y SameSite para impedir el acceso de JavaScript y los ataques CSRF. Mantenga los tokens de acceso de corta duración en memoria en lugar de localStorage o sessionStorage, evitando el robo basado en XSS. 

Para aplicaciones móviles, use iOS Keychain o Android KeyStore. Para la comunicación del servidor, use sistemas de gestión de secretos como HashiCorp Vault o AWS Secrets Manager en lugar de variables de entorno o archivos de configuración.

¿Se pueden cifrar los tokens de autenticación para obtener seguridad adicional?

Los JWT contienen claims codificados en base64 que cualquiera con acceso al token puede leer. Para datos sensibles, use JWE (JSON Web Encryption), que proporciona cifrado de la carga útil mediante estándares como RSA-OAEP-256 o AES-GCM. 

Sin embargo, una mejor práctica consiste en no incluir nunca datos sensibles en las cargas útiles de los tokens. Almacene solo identificadores no sensibles, como ID de usuario y roles. Mantenga los atributos sensibles en bases de datos de backend y recupérelos del lado del servidor mediante identificadores de token.

¿Qué es el token binding y cómo mejora la seguridad?

La vinculación de tokens enlaza criptográficamente los tokens de autenticación con el dispositivo específico donde se emitieron, lo que impide que los atacantes reutilicen tokens robados en sistemas diferentes. El token queda vinculado al Trusted Platform Module (TPM) o Secure Enclave del dispositivo mediante pruebas criptográficas. 

Cuando se presenta el token, el servidor verifica tanto la firma del token como la vinculación del dispositivo. Microsoft Conditional Access y soluciones empresariales similares de gestión de identidad admiten la vinculación de tokens para entornos de alta seguridad.