> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Describe cómo la rotación del token de actualización proporciona mayor seguridad al emitir un nuevo token de actualización con cada solicitud que un cliente que usa tokens de actualización hace a Auth0 para obtener un nuevo token de acceso. # Rotación del token de actualización La rotación del token de actualización es una técnica para obtener nuevos tokens de acceso mediante tokens de actualización que va más allá de la [autenticación silenciosa](/es/docs/authenticate/login/configure-silent-authentication). Los tokens de actualización suelen tener una vida útil más larga y pueden usarse para solicitar nuevos tokens de acceso después de que los tokens de acceso de menor duración expiren. Los tokens de actualización se usan con frecuencia en aplicaciones nativas en dispositivos móviles junto con tokens de acceso de corta duración para ofrecer una experiencia de usuario fluida sin tener que emitir tokens de acceso de larga duración. Con la rotación del token de actualización habilitada en el Auth0 Dashboard, cada vez que una aplicación intercambia un token de actualización para obtener un nuevo token de acceso, también se devuelve un nuevo token de actualización. Por lo tanto, ya no tienes un token de actualización de larga duración que, si se ve comprometido, podría proporcionar acceso ilegítimo a los recursos. Como los tokens de actualización se intercambian e invalidan continuamente, el riesgo se reduce. La forma en que funciona la rotación del token de actualización en Auth0 cumple con [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) y funciona con los siguientes flujos: * [Flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) * [Flujo de código de autorización con Proof Key for Code Exchange](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) * [Flujo de autorización de dispositivo](/es/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) * [Flujo de contraseña del propietario del recurso](/es/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
## Mantener las sesiones de usuario en las SPA
Hasta hace muy poco, las SPA mantenían la sesión del usuario mediante el Flujo de código de autorización con PKCE en combinación con autenticación silenciosa. Los avances recientes en las tecnologías de privacidad de los navegadores, como Intelligent Tracking Prevention (ITP), impiden el acceso a la cookie de sesión de Auth0, lo que obliga a los usuarios a volver a autenticarse. Diagrama de rotación del token de actualización para mantener las sesiones de usuario en las SPA Lamentablemente, los tokens de actualización de larga duración no son adecuados para las SPA porque no existe en el navegador un mecanismo de almacenamiento persistente que pueda garantizar que solo la aplicación prevista tenga acceso. Dado que existen vulnerabilidades que pueden explotarse para obtener estos activos de alto valor y dar a actores maliciosos acceso a recursos protegidos, se ha desaconsejado firmemente el uso de tokens de actualización en las SPA. La rotación del token de actualización ofrece una solución para evitar la pérdida de las sesiones de los usuarios finales debido a efectos secundarios de los mecanismos de privacidad de los navegadores. Como la rotación del token de actualización no depende del acceso a la cookie de sesión de Auth0, no se ve afectada por ITP ni por mecanismos similares. El siguiente diagrama de estado ilustra cómo se usa la rotación del token de actualización junto con el Flujo de código de autorización con PKCE, pero el principio general de obtener un nuevo token de actualización con cada intercambio se aplica a todos los flujos compatibles. Diagrama de estado de la rotación del token de actualización para mantener las sesiones de usuario en las SPA Esto significa que puedes usar tokens de actualización de forma segura para mitigar los efectos adversos de las herramientas de privacidad de los navegadores y proporcionar acceso continuo a los usuarios finales sin interrumpir la experiencia de usuario.
## Detección automática de reutilización
Cuando un cliente necesita un nuevo token de acceso, envía el token de actualización con la solicitud a Auth0 para obtener un nuevo par de tokens. En cuanto Auth0 emite el nuevo par, el token de actualización usado en la solicitud se invalida. Esto protege tu aplicación frente a ataques de repetición derivados de tokens comprometidos. Sin imponer restricciones vinculadas al remitente, es imposible que el servidor de autorización sepa qué actor es legítimo o malicioso en caso de un ataque de repetición. Por eso, es importante que el token de actualización emitido más recientemente también se invalide de inmediato cuando se envía al servidor de autorización un token de actualización usado previamente (ya invalidado). Esto evita que cualquier token de actualización de la misma familia de tokens (todos los tokens de actualización derivados del token de actualización original emitido para el cliente) pueda usarse para obtener nuevos tokens de acceso. Por ejemplo, considera el siguiente escenario: Diagrama de estados de detección de reutilización de la rotación del token de actualización 1. El Cliente legítimo tiene el **token de actualización 1**, y este se filtra o lo roba el Cliente malicioso. 2. El Cliente legítimo usa el **token de actualización 1** para obtener un nuevo par de token de actualización y token de acceso. 3. Auth0 devuelve el **token de actualización 2/token de acceso 2**. 4. El Cliente malicioso intenta entonces usar el **token de actualización 1** para obtener un token de acceso. Auth0 reconoce que el token de actualización 1 se está reutilizando e invalida de inmediato la familia de tokens de actualización, incluido el **token de actualización 2**. 5. Auth0 devuelve una respuesta de acceso denegado al Cliente malicioso. 6. El **token de acceso 2** vence y el Cliente legítimo intenta usar el **token de actualización 2** para solicitar un nuevo par de tokens. Auth0 devuelve una respuesta de acceso denegado al Cliente legítimo. 7. Se requiere reautenticación. Este mecanismo de protección funciona independientemente de si el cliente legítimo o el cliente malicioso logra intercambiar el **token de actualización 1** por un nuevo par de tokens antes que el otro. En cuanto se detecta la reutilización, se denegarán todas las solicitudes posteriores hasta que el usuario vuelva a autenticarse. Cuando se detecta una reutilización, Auth0 registra en los logs los [eventos](/es/docs/deploy-monitor/logs/log-event-type-codes) detectados (como `ferrt`, que indica un intercambio fallido). Esto puede resultar especialmente útil junto con las capacidades de [Log Streaming](/es/docs/customize/log-streams) de Auth0 para detectar actividad sospechosa. Otro ejemplo es cuando el cliente malicioso roba el **token de actualización 1** y logra usarlo para obtener un token de acceso antes de que el cliente legítimo intente usar el **token de actualización 1**. En este caso, el acceso del cliente malicioso sería de corta duración porque el **token de actualización 2** (o cualquier token de actualización emitido posteriormente) se revoca automáticamente cuando el cliente legítimo intenta usar el **token de actualización 1**, como se muestra en el siguiente diagrama: Diagrama de estados de detección de reutilización de la rotación del token de actualización
## Compatibilidad con SDK
Los siguientes SDK son compatibles con la rotación del token de actualización y la detección automática de reutilización. * SDK de SPA de Auth0 * Flutter (Web) * SDK de Swift (iOS) * SDK de Android * Flutter * SDK de React Native * WPF / Winforms * Xamarin Para consultar la documentación específica de estos SDK, visita la página [Bibliotecas de SDK de Auth0](/es/docs/libraries). Puedes elegir almacenar los tokens en el almacenamiento local o en la memoria del navegador. De forma predeterminada, se almacenan en la memoria del navegador. Consulta [Prácticas recomendadas para tokens](/es/docs/secure/tokens/token-best-practices) para ver recomendaciones sobre el almacenamiento de tokens. Debes habilitar el acceso sin conexión y solicitar el scope offline\_access en el SDK del cliente.
## Más información
* [Configurar la rotación del token de actualización](/es/docs/secure/tokens/refresh-tokens/configure-refresh-token-rotation) * [Deshabilitar la rotación del token de actualización](/es/docs/secure/tokens/refresh-tokens/disable-refresh-token-rotation) * [Configurar la caducidad del token de actualización](/es/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration) * [Prácticas recomendadas para tokens](/es/docs/secure/tokens/token-best-practices)