Refresh Token vs Access Token: ¿Cuál es la diferencia y por qué importa en Microsoft Entra ID?

By Mirko Peters · 2026-04-28

Refresh Token vs Access Token: ¿Cuál es la diferencia y por qué importa en Microsoft Entra ID?

Automatically translated with AI from the original post. Read the English original

Si alguna vez te has preguntado qué diferencia realmente a un refresh token de un access token, has llegado al lugar adecuado. En el mundo de Microsoft Entra ID y la seguridad cloud moderna, estos dos tipos de token son los que llevan la voz cantante: cada uno tiene su función, sus particularidades y sus reglas de seguridad. Dominar estas diferencias puede salvarte el pellejo al diseñar flujos de inicio de sesión seguros para Microsoft 365, Azure o cualquier aplicación vinculada a la plataforma Entra.

Y no es solo teoría. Saber qué token usar y cuándo, dónde almacenarlo y cómo protegerlo es una habilidad básica para cualquier profesional de TI, desarrollador o administrador del ecosistema Microsoft. La elección afecta no solo a la postura de seguridad de tu aplicación, sino también a la experiencia diaria de los usuarios, sobre todo en lo relativo a mantener la sesión iniciada o a recuperarse de incidentes de seguridad.

A lo largo de esta guía verás exactamente cómo encajan los access tokens y los refresh tokens en las configuraciones de autenticación y autorización, por qué importa su duración y qué hace única a cada uno, especialmente en entornos de Microsoft Entra ID. Al final sabrás cómo equilibrar medidas de seguridad sólidas con una buena experiencia de usuario mientras navegas por el complejo panorama de la gestión de tokens en la nube.

Entender los tokens en la autenticación moderna

La autenticación moderna consiste en conceder los permisos adecuados en el momento adecuado, y los tokens digitales son los protagonistas. Si tienes una aplicación o servicio en línea, probablemente ya estés usando tokens, aunque aún no te des cuenta. Son los intermediarios que permiten a las aplicaciones avalarte ante un servicio cloud sin que tengas que entregar tu contraseña cada vez.

Los tokens son el núcleo del marco OAuth 2.0, que impulsa los inicios de sesión y el acceso seguro en plataformas como Microsoft Entra ID. En lugar de gestionar identificadores de sesión o cookies frágiles, las aplicaciones confían ahora en estos "pases" digitales para identificar a los usuarios y conceder acceso a recursos cloud sensibles. Este cambio ha hecho que la seguridad sea más estricta y, al mismo tiempo, más cómoda para las grandes organizaciones que migran a la nube.

La clave está en contar con distintos tipos de token para distintas funciones. Algunos están pensados para un acceso temporal: rápidos y desechables. Otros mantienen las sesiones activas en segundo plano, para que puedas trabajar todo el día sin tener que volver a iniciar sesión constantemente. Esa distinción entre access tokens y refresh tokens es fundamental para que los servicios cloud de Microsoft, incluido Entra ID, equilibren la experiencia del usuario y la seguridad de la organización.

Esta sección sienta las bases que necesitas: qué es un token, qué tipos existen y por qué sus funciones son tan importantes en el panorama actual de la autenticación. Vamos a entrar en detalle, empezando por la pregunta más fundamental: ¿qué es exactamente un token?

¿Qué es un token?

Un token, en seguridad digital, es un fragmento compacto de datos que actúa como credencial digital. Piénsalo como una versión digital de una tarjeta de acceso: algo que una aplicación presenta para demostrar tu identidad o tus permisos ante otro sistema. Los tokens pueden usarse para autenticación (¿eres quien dices ser?) y para autorización (¿tienes permiso para hacer lo que estás haciendo?) en aplicaciones y APIs cloud.

Los tokens suelen basarse en estándares modernos como OAuth 2.0 y, con frecuencia, son tokens de portador (bearer), como los JSON Web Tokens (JWT). Se prefieren frente a los identificadores de sesión clásicos porque son más portables, pueden contener claims estructurados y permiten un acceso seguro a recursos cloud y sistemas distribuidos.

¿Qué son los access tokens?

Los access tokens son credenciales digitales de corta duración que se entregan a una aplicación tras una autenticación correcta. Su función principal es conceder acceso temporal y muy acotado a recursos concretos, como APIs, datos de usuario o almacenamiento cloud, sin exponer contraseñas ni otros datos sensibles.

Estos tokens solo son válidos durante un tiempo limitado, normalmente entre 30 y 90 minutos en Microsoft Entra ID. Son los que las aplicaciones envían con cada solicitud a una API para demostrar que el usuario está autorizado. Siguiendo los estándares de OAuth 2.0, los access tokens funcionan en Microsoft 365, Azure y cualquier servicio conectado a Entra ID, y ofrecen permisos granulares y limitados en el tiempo.

¿Qué son los refresh tokens?

Los refresh tokens son credenciales persistentes que se entregan a aplicaciones de confianza tras el inicio de sesión inicial. A diferencia de los access tokens, la función principal de un refresh token es obtener silenciosamente nuevos access tokens cuando el actual caduca, sin que el usuario tenga que autenticarse de nuevo.

Esto significa que un token de actualización ayuda a mantener sesiones de larga duración y reduce la necesidad de que los usuarios inicien sesión repetidamente. En los entornos de Microsoft, los tokens de actualización son esenciales para una experiencia de usuario fluida, ya que permiten que las aplicaciones renueven el acceso en segundo plano, de forma silenciosa, entre sesiones y dispositivos, e incluso después de fallos de red, manteniendo a la vez protegidas las credenciales sensibles.

Diferencias clave entre el token de acceso y el token de actualización

A primera vista, los tokens de acceso y los tokens de actualización pueden parecer simples cadenas aleatorias, pero sus funciones y su duración son muy distintas. No son intercambiables: están diseñados para fines muy concretos dentro del flujo de autenticación de Microsoft Entra ID.

Los tokens de acceso son tu "pase de acceso" para llamar a las API y obtener datos, pero solo durante un periodo corto. Tienen una vida útil breve a propósito, para reducir el riesgo de seguridad, sobre todo si llegan a filtrarse. Los tokens de actualización, en cambio, duran más. Su función es mantener la experiencia del usuario fluida, reautorizando discretamente en segundo plano.

Entender estas diferencias no es un ejercicio meramente teórico. Si eliges la estrategia equivocada o almacenas el token incorrecto en el lugar equivocado, o bien frustrarás a los usuarios con demasiados inicios de sesión, o bien dejarás huecos importantes en tu configuración de seguridad. En este bloque de secciones se explica qué hace cada token, cuánto dura y qué lo hace seguro (o arriesgado) en la práctica, no solo en teoría.

Si estás diseñando una arquitectura para Microsoft 365, Azure o cualquier servicio conectado a Entra ID, presta atención a las siguientes diferencias. Determinan el equilibrio de tu aplicación entre una seguridad sólida y sesiones fluidas e ininterrumpidas para todos los usuarios.

Funciones: qué hace cada uno

Los tokens de acceso son tu billete para desbloquear las API y los recursos en la nube, pero solo te llevan hasta cierto punto. Cuando el token de acceso caduca, te quedas sin acceso, a menos que también tengas un token de actualización. El token de actualización es el pase entre bastidores que permite a tu aplicación solicitar discretamente un nuevo token de acceso sin volver a molestar al usuario.

Así, en el mundo de la nube de Microsoft 365 y Azure, los tokens de acceso se encargan de las acciones "en este momento", mientras que los tokens de actualización garantizan que esas acciones puedan seguir ejecutándose en segundo plano, sesión tras sesión. Esta combinación crea flujos de trabajo seguros y evita los constantes dolores de cabeza de la reautenticación.

Duración de los tokens y por qué importa la caducidad

Los tokens de acceso tienen una vida útil corta por un motivo: por defecto, en Entra ID suele ser de entre 30 y 90 minutos. Están pensados para conceder solo el acceso necesario antes de caducar, lo que reduce el riesgo si el token se filtra. Los tokens de actualización, en cambio, son los corredores de fondo: suelen durar días, semanas o incluso meses, según las necesidades de la aplicación y las directivas de seguridad configuradas.

Esta diferencia es importante porque los tokens de vida corta implican menos exposición, pero también requieren más renovaciones. Los tokens de actualización de larga duración favorecen sesiones ininterrumpidas, pero aumentan los riesgos si caen en manos equivocadas. La clave está en equilibrar la seguridad con la comodidad del usuario.

Características de seguridad de los tokens de acceso y de actualización

• 1. Seguridad del token de acceso: Los tokens de acceso están pensados para un uso inmediato y temporal. Como normalmente duran menos de una hora, la ventana de riesgo es pequeña si alguien los roba. Sin embargo, como son tokens de portador (cualquiera que los tenga puede usarlos), deben transmitirse únicamente por HTTPS y almacenarse en memoria, nunca en un almacenamiento persistente en el cliente.
• 2. Seguridad del token de actualización: Los tokens de actualización son de larga duración y más sensibles. Si un token de actualización se ve comprometido, un atacante podría obtener nuevos tokens de acceso de forma persistente, incluso después de que el usuario cierre sesión. Por eso, el almacenamiento seguro es fundamental; lo ideal es un enclave seguro (como un almacén respaldado por hardware en dispositivos móviles o cookies seguras solo HTTP en los navegadores).
• 3. Superficies de ataque: Los tokens de acceso podrían interceptarse en tránsito si no se aplica HTTPS o encontrarse en volcados de memoria. Los tokens de actualización, si se almacenan en el almacenamiento local o de sesión, son muy vulnerables a los ataques de cross-site scripting (XSS). Para reforzar la protección en entornos de Microsoft, aplica directivas de acceso condicional y supervisa el uso anómalo de los tokens.
• 4. Revocación y riesgo: Los tokens de acceso normalmente no se pueden revocar antes de que caduquen, ya que suelen ser JWT sin estado. Los tokens de actualización, en cambio, pueden revocarse o invalidarse activamente por el servidor de autorización si se detecta un compromiso. Para conocer los riesgos reales y los controles aplicables a los tokens persistentes, consulta esta visión general de los ataques de consentimiento de OAuth en Entra ID, donde los atacantes abusan del acceso persistente mediante tokens de actualización.
• 5. Mitigaciones en la nube de Microsoft: Combinar tokens de acceso de corta duración, controles de consentimiento estrictos, registros sólidos y la aplicación del consentimiento de administrador puede ayudar a reducir el riesgo. La gobernanza de la seguridad, tal como se explica en este episodio del podcast sobre la gobernanza de seguridad de Entra ID, debe implementarse para gestionar la dispersión de identidades y aplicar directivas de seguridad más eficaces.

Tokens de acceso de corta duración para reducir el riesgo

La decisión de diseño de mantener los tokens de acceso de corta duración no es paranoia, sino una gestión inteligente del riesgo. Si un token de acceso de corta duración es robado, la ventana de ataque es mínima. Pierde su validez en una hora o menos, lo que frena la mayoría de los intentos de movimiento lateral e incidentes de reproducción de tokens.

En sistemas distribuidos como Microsoft 365 y Azure, esto también garantiza que los cambios en los permisos de usuario o las acciones de cierre de sesión se apliquen rápidamente. Una caducidad rápida significa que cualquier uso no autorizado de un token tiene un margen muy reducido, lo que permite responder con rapidez sin necesidad de listas centralizadas de revocación para cada token en circulación.

Tokens de actualización persistentes para una reautenticación sin interrupciones

Los tokens de actualización persistentes buscan, sobre todo, que el usuario trabaje sin fricciones. En lugar de mostrarle una pantalla de inicio de sesión cada hora, un token de actualización permite a las aplicaciones «canjear» los tokens de acceso caducados por otros nuevos, a menudo de forma silenciosa e instantánea. Esto marca una gran diferencia en la productividad, sobre todo con las aplicaciones de Microsoft 365 que se usan todo el día o con clientes móviles con conectividad irregular.

¿El inconveniente? Los tokens de actualización de mayor duración conllevan más riesgo si se ven comprometidos. Por eso, las aplicaciones bien diseñadas añaden mecanismos de revocación y directivas de acceso condicional, equilibrando los beneficios de la reautenticación sin interrupciones frente al potencial de uso indebido si un token se filtra.

Gestión del ciclo de vida de los tokens en Microsoft Entra ID

Obtener tokens es solo la mitad del trabajo: gestionarlos a lo largo del tiempo es lo que realmente marca la diferencia en seguridad y en experiencia de usuario. En Microsoft Entra ID, el ciclo de vida de un token abarca desde el momento en que se crea un token de acceso o de actualización hasta la forma y el momento en que se renueva, rota o revoca por completo.

Este proceso se rige por las buenas prácticas de OAuth 2.0 y por los mecanismos específicos de Microsoft para el control de sesiones. Hay que tener en cuenta amenazas en tiempo real (como los ataques de reproducción), problemas de temporización (como el desfase de reloj) y los detalles de los sistemas globales distribuidos. Hacerlo bien implica conocer la rotación de tokens, los pasos de validación y las vías de revocación.

Siguiendo el enfoque de Microsoft, las organizaciones pueden usar la aplicación de directivas, los controles de administración y un registro detallado para gestionar la dispersión de tokens, sobre todo a medida que aumenta el número de dispositivos conectados a la nube. Para saber más sobre cómo escalar las directivas de seguridad de identidad en entornos grandes, encontrarás orientación práctica sobre gobernanza en este episodio del podcast sobre acceso condicional de Entra ID y reducción de riesgos.

A continuación veremos cómo rotar y renovar tokens, cómo Entra ID emite y comprueba los tokens, y qué aspectos de temporización y de implementación hay que vigilar. Si haces bien estos pasos, tanto tus aplicaciones como tus usuarios te lo agradecerán.

Mejores prácticas de rotación y renovación de tokens

• 1. Rota los tokens con frecuencia: Renueva siempre los tokens de acceso al caducar; no intentes extender su validez. En los tokens de actualización, adopta la rotación en cada uso: cada vez que se utilice para obtener un nuevo token de acceso, sustitúyelo por un nuevo token de actualización. Así se dificulta que un atacante aproveche uno anterior que haya robado.
• 2. Invalida los tokens ya utilizados: Establece como práctica habitual revocar («incluir en la lista negra») un token de actualización en cuanto se sustituya por uno nuevo. Así, solo el token de actualización emitido más recientemente sigue siendo válido, lo que reduce la ventana potencial para ataques de reproducción.
• 3. No expongas los tokens a clientes no seguros: Nunca envíes tokens de actualización a clientes públicos de front-end, como las aplicaciones de una sola página (SPA), a menos que sea absolutamente necesario, y solo con controles adicionales como Proof Key for Code Exchange (PKCE).
• 4. Supervisa el uso sospechoso: Usa la supervisión integrada de Microsoft Entra ID y las notificaciones para administradores ante un uso inusual de tokens, por ejemplo, tokens de actualización reutilizados desde distintas ubicaciones o dispositivos. Automatiza las respuestas de acceso condicional para cerrar las sesiones comprometidas y limitar el alcance del daño.
• 5. Cumplimiento en las aplicaciones principales: Microsoft 365, Azure AD y las aplicaciones habilitadas para Entra ID ofrecen compatibilidad integrada con patrones de rotación de tokens. Adopta sus directivas predeterminadas como mínimo (por ejemplo, tokens de actualización de un solo uso para Exchange Online) y, después, refuérzalas según sea necesario para las cargas de trabajo sensibles.

Cómo se emiten y validan los tokens en Entra ID

• 1. Emisión de tokens (servidor de autorización): Tras una autenticación correcta, Microsoft Entra ID (el servidor de autorización) emite un token de acceso y, si se solicita, un token de actualización. Normalmente son JWT, firmados digitalmente con algoritmos de firma robustos (como RS256) y con claves privadas gestionadas por Microsoft.
• 2. Notificaciones y contenido del token: El token de acceso contiene notificaciones (claims) con datos sobre el usuario, sus permisos (ámbitos) e información de caducidad. Los tokens de actualización son opacos y contienen la información que Entra ID necesita para renovar las sesiones de forma segura.
• 3. Validación en los servidores de recursos: Cuando tu aplicación o API recibe un token de acceso, comprueba su firma digital con una clave pública de firma publicada (del endpoint JWKS de Entra ID). La validación garantiza que el token es auténtico, que no ha sido manipulado y que sigue siendo válido (no ha caducado ni se ha revocado).
• 4. Comprobaciones de seguridad: Entra ID admite comprobaciones de audiencia, aplicación de ámbitos y validación de firma en cada servidor de recursos o API. En las aplicaciones críticas, comprueba siempre estas notificaciones y verifica la firma antes de conceder el acceso.
• 5. Revocación y listas negras: Los tokens de actualización, a diferencia de los tokens de acceso sin estado, pueden ser revocados por Entra ID, lo que permite responder de inmediato ante un posible compromiso. Los administradores pueden forzar cierres de sesión o limitar la validez de los tokens mediante cambios en las directivas.

Periodos de gracia y matices de implementación

Los periodos de gracia suavizan los pequeños desajustes temporales que se producen en la autenticación basada en tokens. Como los servidores y los clientes suelen tener relojes ligeramente diferentes, un problema conocido como desfase de reloj (clock skew), Microsoft Entra ID incluye un margen de tolerancia (normalmente unos 5 minutos) al comprobar la caducidad de los tokens. Así se evita que los inicios de sesión fallen por diferencias de tiempo de una fracción de segundo.

Para obtener los mejores resultados, mantén sincronizados los relojes de todos los servidores mediante NTP y ten en cuenta que las implementaciones de alta disponibilidad o multirregión pueden ampliar ligeramente los periodos de caducidad de los tokens. Usa las recomendaciones de la documentación de Entra ID sobre los periodos de gracia y prueba siempre el comportamiento con tráfico real, sobre todo en el caso de usuarios que se desplazan entre regiones o zonas horarias.

Almacenamiento seguro y gestión de tokens en aplicaciones cliente

Por muy robusto que sea un token, su seguridad depende del lugar donde lo guardes. Por eso, el almacenamiento y la gestión seguros son la preocupación más práctica para cualquier aplicación que utilice la autenticación de Microsoft Entra ID. El lugar donde guardes un token de acceso o de actualización depende del cliente: navegador, móvil o escritorio. Cada entorno tiene sus ventajas, sus puntos ciegos y sus trampas habituales.

Si crees que guardar tokens en localStorage del navegador es inofensivo, piénsatelo de nuevo: basta un único ataque XSS para que el token quede expuesto. Las aplicaciones móviles parecen más seguras, pero el rooting o el jailbreaking también pueden exponer tokens que se consideraban «seguros». Y en las aplicaciones de una sola página (SPA) ni siquiera existe una opción de almacenamiento seguro que los scripts maliciosos no puedan alcanzar.

Esta sección te ofrece la orientación necesaria para elegir las opciones de almacenamiento adecuadas en cada tipo de aplicación. Verás un desglose de opciones prácticas (cookies seguras solo HTTP, memoria de sesión del navegador y almacenes seguros específicos de cada plataforma) y los pasos imprescindibles para proteger los tokens persistentes. También verás por qué hace falta prestar especial atención a los clientes públicos, donde los secretos de cliente no pueden ocultarse, lo que te llevará a un plan de almacenamiento y rotación consciente de los riesgos para cada escenario.

La seguridad de tu aplicación depende de estas decisiones, así que no lo dejes al azar. Conoce los patrones seguros e inseguros que determinan si tu aplicación resiste o cae ante el primer indicio de robo de tokens.

Almacenamiento seguro de tokens de actualización en los distintos tipos de cliente

• 1. Aplicaciones web (navegadores): El lugar más seguro para almacenar tokens de actualización en los navegadores es una cookie HTTP-only y Secure. A diferencia de localStorage o sessionStorage, JavaScript no puede leer estas cookies, lo que las hace inmunes a XSS. No almacenes tokens en localStorage: es vulnerable a ataques basados en scripts y no debería guardar nada sensible.
• 2. Aplicaciones de una sola página (SPA): Las SPA no disponen de almacenamiento persistente seguro. Lo mejor que puedes hacer es mantener los tokens en la memoria del navegador (variables de JavaScript) durante la vida de la sesión. Cuando la página se recarga, los tokens desaparecen, lo que minimiza el riesgo. Nunca guardes tokens de actualización en almacenes o cookies que no controles, y apóyate lo máximo posible en tokens de acceso de corta duración y en renovaciones silenciosas.
• 3. Aplicaciones móviles: Usa el almacén seguro de credenciales del dispositivo (Llavero de iOS o Android Keystore) para guardar los tokens de actualización. Estos almacenes protegidos por la plataforma están diseñados para bloquear el acceso de otras aplicaciones y de los procesos del sistema; incluso si el teléfono está comprometido o rooteado, extraerlos resulta difícil.
• 4. Aplicaciones de escritorio: Usa los administradores de credenciales del sistema operativo (como el Credential Locker de Windows) para almacenar tokens persistentes. Nunca los escribas en archivos de texto sin cifrar ni en carpetas de usuario donde el malware pueda obtenerlos.
• 5. Límite empresarial: En todos los casos, aplica controles adicionales como el cifrado del dispositivo, el bloqueo de pantalla del usuario y las capacidades de borrado remoto. Para cargas de trabajo especialmente sensibles, exige autenticación de paso adicional (step-up) antes de mostrar o usar un token de actualización almacenado en el dispositivo.

Consideraciones especiales para la rotación de tokens en clientes públicos

• 1. Los clientes públicos no pueden almacenar secretos: Los clientes públicos (SPA y algunas aplicaciones móviles) no pueden ocultar de forma segura los tokens de actualización ni los secretos de cliente. Asume que cualquier cosa almacenada puede quedar expuesta.
• 2. Usa solo tokens de acceso de corta duración: Reduce o elimina los tokens de actualización siempre que sea posible. Apóyate en tokens de acceso de corta duración y solicita una nueva autenticación interactiva en lugar de mantener la persistencia a largo plazo.
• 3. Rota los tokens en cada uso: Si necesitas usar tokens de actualización, implementa patrones de rotación de un solo uso: emite un nuevo token de actualización en cada concesión y revoca el anterior.
• 4. Combínalo con PKCE para mayor seguridad: Exige Proof Key for Code Exchange (PKCE) en los flujos de OAuth, lo que bloquea la mayoría de los ataques de interceptación incluso en entornos expuestos.

Buenas prácticas para la gestión de tokens de acceso y de actualización

Conocer las reglas de seguridad de los tokens es una cosa; llevarlas a la práctica día a día es otra. Cuando trabajas con datos sensibles de Microsoft 365, cargas de trabajo en Azure o cualquier escenario de Entra ID, lo que está en juego es mayor: debes combinar una protección hermética con una experiencia de usuario que no haga que la gente se queje por tener que iniciar sesión tantas veces.

Esta sección recoge lo que sí debes hacer y lo que debes evitar al gestionar tokens de actualización y de acceso a gran escala. Seamos realistas: la nube de Microsoft tiene sus particularidades, desde el acceso condicional complejo hasta la estrecha integración con Microsoft Defender y Microsoft Purview para la supervisión y la gobernanza. Las buenas prácticas aquí abarcan todas las fases: emisión de tokens, almacenamiento seguro, rotación, uso y, cuando llega el momento, cómo cortar el acceso rápidamente si algo sale mal.

Atento a los consejos prácticos que puedes aplicar ya mismo, para que tus aplicaciones cumplan la doble promesa de «más fluidas y más seguras». ¿Quieres más información sobre cómo reforzar la postura de seguridad de Microsoft 365 sin perjudicar la productividad de los usuarios? No te pierdas esta guía más amplia sobre cómo blindar la seguridad de M365 sin molestar a los usuarios, que cubre Defender, Purview y el acceso condicional en entornos de Entra ID.

A continuación encontrarás un resumen de las reglas básicas para elegir, gestionar y proteger los tokens de acceso y de actualización en cualquier implementación basada en Microsoft.

Puntos clave sobre la elección y el manejo de tokens

• Usa los tokens de acceso solo para acceder de inmediato y a corto plazo a los recursos; recurre a los tokens de actualización únicamente cuando las sesiones persistentes y sin interrupciones sean imprescindibles y los controles de seguridad estén implementados.
• Almacena los tokens de forma segura, utilizando almacenes protegidos por la plataforma, como cookies HTTP-only para la web, llaveros para dispositivos móviles y gestores de credenciales para aplicaciones de escritorio. Nunca guardes tokens sensibles en texto plano ni en localStorage del navegador.
• Implementa la rotación y la revocación de tokens, asegurando que los tokens de actualización se reemplacen y que los anteriores se invaliden en cada proceso de renovación para limitar las ventanas de ataque.
• Equilibra la duración de la sesión con la experiencia de usuario; evita configurar tokens de acceso tan cortos que los usuarios reciban constantemente solicitudes para iniciar sesión, pero no los hagas tan largos que creen una exposición innecesaria si un token se filtra.
• Supervisa, gobierna y audita el uso de los tokens— intégralos con herramientas como Microsoft Defender y Purview, y aplica Conditional Access en escenarios de inicio de sesión de riesgo. Revoca el acceso de inmediato si se sospecha o se detecta un compromiso.

Conclusión y comprobación rápida de conocimientos

Entender la diferencia entre los tokens de acceso y los tokens de actualización no es solo un trámite dentro del proceso de OAuth 2; es clave para crear experiencias seguras y fluidas en la plataforma de identidad de Microsoft, como Entra ID. Encontrar el equilibrio adecuado entre tiempos de vida cortos de los tokens por seguridad y ciclos de actualización más largos por comodidad es todo un arte, sobre todo cuando gestionas sesiones de usuario en varios dispositivos o servicios.

¿Listo para una comprobación rápida de conocimientos? Pregúntate: ¿cómo gestionarías la caducidad de los tokens en una aplicación con conexión a Internet inestable? ¿Deberían llegar alguna vez los tokens de actualización a tus microservicios de backend? Si este repaso te ha ayudado o te ha enseñado algo nuevo, considera compartir tu opinión: los comentarios más destacados abren puertas y fortalecen a toda la comunidad. ¿Te ha gustado lo que has visto? ¡Quédate y sigue afinando esas habilidades de seguridad!