Almacenamiento de tokens

Aprende cómo y dónde almacenar los tokens utilizados en la autenticación basada en tokens.

Descripción general

Conceptos clave

• La forma en que decidas almacenar el token es fundamental para proteger tu aplicación frente a ataques maliciosos.
• Revisa los escenarios de cada tipo de aplicación.
• Decide qué método se adapta mejor a tu tecnología.

Proteger las SPA que realizan llamadas a API conlleva sus propias consideraciones. Debes asegurarte de que los tokens y otros datos sensibles no sean vulnerables a cross-site scripting (XSS) ni puedan ser leídos por JavaScript malicioso.

Para obtener más información, consulta JWT Handbook y The Ultimate Guide to Next.js Authentication with Auth0.

​

Escenarios de sitios estáticos de Next.js

Cuando estás creando una aplicación Next.js, la autenticación puede ser necesaria en los siguientes casos:

1. Al acceder a una página
2. Al acceder a una ruta de API
3. Cuando tu aplicación llama a una API alojada fuera de tu aplicación Next.js en nombre del usuario

Cuando hay un servidor disponible, tu aplicación puede gestionar la interacción con Auth0 y crear una sesión, pero en este modelo no tenemos un backend. Todo el trabajo ocurre en el frontend:

1. El usuario es redirigido a Auth0.

2. Cuando el usuario haya iniciado sesión correctamente, será redirigido de vuelta a la aplicación.

3. El cliente completará el intercambio del código de autorización con Auth0 y recuperará el id_token y el access_token del usuario, que se almacenarán en memoria.

   

Aplicación web tradicional

Si tu aplicación usa un escenario de inicio de sesión que no requiere llamadas a la API, solo se necesita un token de ID. No es necesario almacenarlo. Puedes validarlo y obtener de él los datos que necesites.

Si tu aplicación necesita llamar a APIs en nombre del usuario, se necesitan tokens de acceso y, opcionalmente, tokens de actualización. Estos pueden almacenarse del lado del servidor o en una cookie de sesión. La cookie debe estar cifrada y tener un tamaño máximo de 4 KB. Si los datos que se van a almacenar son muchos, almacenar tokens en la cookie de sesión no es una opción viable.

Usa los siguientes tipos de flujo en estos escenarios:

• Authorization Code Flow
• Guías de inicio rápido para aplicaciones web regulares

Aplicación nativa/móvil

Almacena los tokens en un almacenamiento seguro que ofrezca el sistema operativo y limita el acceso a ese almacenamiento. Por ejemplo, usa KeyStore para Android y KeyChain para iOS.

Usa los siguientes tipos de flujo en estos escenarios:

• Authorization Code Flow with Proof Key for Code Exchange
• Guardar y renovar tokens para Swift
• Guías de inicio rápido para aplicaciones nativas/móviles

Aplicación de página única

Recomendamos usar el Auth0 SPA SDK para que gestione por ti el almacenamiento de tokens, la gestión de sesiones y otros detalles.

Cuando la SPA llama únicamente a una API servida desde un dominio que puede compartir cookies con el dominio de la SPA, no se necesitan tokens. OAuth añade vectores de ataque adicionales sin aportar valor extra y debe evitarse en favor de un enfoque tradicional basado en cookies.

Cuando la SPA llama a varias APIs que residen en un dominio diferente, se necesitan tokens de acceso y, opcionalmente, tokens de actualización.

• Si el backend de la SPA puede gestionar las llamadas a la API, entonces funciona de forma similar a una aplicación web tradicional que gestiona tokens del lado del servidor mediante:

  • Authorization Code Flow
  • Authorization Code Flow with Proof Key for Code Exchange

• Si el backend de la SPA no puede gestionar las llamadas a la API, entonces funciona de forma similar a una aplicación móvil que almacena tokens en el backend de la SPA, pero la SPA necesita obtener los tokens desde el backend para realizar solicitudes a la API. Se debe establecer un protocolo entre el backend y la SPA para permitir la transferencia segura del token desde el backend a la SPA.

• Si tienes una SPA sin un servidor backend correspondiente, tu SPA debe solicitar nuevos tokens al iniciar sesión y almacenarlos en memoria sin ningún tipo de persistencia. Para hacer llamadas a la API, tu SPA usaría entonces la copia en memoria del token.

De conformidad con las especificaciones de OAuth2, cuando un navegador solicita un Token de actualización desde el endpoint /token, Auth0 solo devolverá un Token de actualización si Refresh Token Rotation está habilitada para ese cliente.

Para obtener más detalles, consulta Auth0 SPA SDK en GitHub.

​

Escenarios de almacenamiento en memoria en el navegador

Auth0 recomienda almacenar los tokens en la memoria del navegador como la opción más segura. Usar Web Workers para gestionar la transmisión y el almacenamiento de los tokens es la mejor forma de protegerlos, ya que los Web Workers se ejecutan en un ámbito global separado del resto de la aplicación. Use Auth0 SPA SDK, cuya opción de almacenamiento predeterminada es el almacenamiento en memoria mediante Web Workers.

Si no puede usar Web Workers, Auth0 recomienda como alternativa usar clausuras de JavaScript para emular métodos privados.

Use Auth0 SPA SDK, cuya opción de almacenamiento predeterminada es el almacenamiento en memoria, para aprovechar tanto Web Workers como clausuras de JavaScript según el tipo de token.

El método de almacenamiento en memoria en el navegador no ofrece persistencia entre recargas de la página ni entre pestañas del navegador.

​

Escenarios de almacenamiento local del navegador

Usar el almacenamiento local del navegador puede ser una alternativa viable a los mecanismos que requieren recuperar el token de acceso desde un iframe y a la autenticación basada en cookies entre dominios cuando esto no es posible debido a restricciones del navegador (por ejemplo, ITP2).

Almacenar tokens en el almacenamiento local del navegador permite mantenerlos entre recargas de página y pestañas del navegador. Sin embargo, si un atacante logra ejecutar JavaScript en la SPA mediante un ataque de cross-site scripting (XSS), puede recuperar los tokens almacenados en el almacenamiento local. Una vulnerabilidad que permita llevar a cabo un ataque XSS con éxito puede estar en el código fuente de la SPA o en cualquier código JavaScript de terceros (como Bootstrap, jQuery o Google Analytics) incluido en la SPA.

Para reducir los riesgos de seguridad si tu SPA usa flujos implícitos (en su lugar, te recomendamos usar el flujo de código de autorización con PKCE) o híbridos, puedes reducir el tiempo absoluto de expiración del token. Esto reduce el impacto de un ataque XSS reflejado (pero no de uno persistente). Para reducir el tiempo de expiración, ve a Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds).

Reduce al mínimo necesario la cantidad de código JavaScript de terceros incluido desde una fuente externa a tu dominio (como enlaces a jQuery, Bootstrap, Google Analytics, etc.). Reducir el código JS de terceros disminuye la probabilidad de una vulnerabilidad XSS. También es más seguro realizar comprobaciones de Subresource Integrity (SRI) en scripts de terceros (cuando sea posible) para verificar que los recursos obtenidos se entregan sin manipulaciones inesperadas.

​

Más información

• ID Tokens
• Tokens de acceso
• Tokens de actualización
• Prácticas recomendadas para tokens