El manejo seguro de los tokens de autenticación es fundamental para la seguridad de las aplicaciones. El mejor enfoque suele depender del tipo de aplicación (web, móvil, del lado del servidor) y del token específico que se utilice (token de acceso, token de actualización).

A continuación se presentan los principios generales y las mejores prácticas para manejar los tokens de autenticación de forma segura:

Principios generales

• Manténgalos en secreto, manténgalos a salvo: trate los tokens como cualquier otra credencial confidencial. La clave de firma de los tokens solo debe revelarse a los servicios que la requieran.
• Adopte HTTPS: transmita siempre los tokens a través de conexiones HTTPS seguras para evitar su interceptación.
• Minimice los datos confidenciales en la carga útil: no incluya datos confidenciales del usuario en la carga útil del token, ya que los tokens se descodifican fácilmente, incluso si están firmados.
• Plazos de caducidad cortos: establezca plazos de caducidad cortos para los tokens de acceso (de minutos a horas) para limitar las oportunidades de los atacantes si se compromete un token.
• Evite el código fijo: Nunca codifique los tokens ni los almacene en texto plano dentro de la aplicación.

Almacenamiento de tokens por tipo de aplicación

1. Aplicaciones web

• Almacenamiento en memoria (para tokens de acceso en SPA): almacenar tokens de acceso en la memoria del navegador se considera una opción segura, ya que mitiga los riesgos asociados al almacenamiento en el sistema de archivos. Esto se puede lograr utilizando cierres de JavaScript o Web Workers, que se ejecutan en un ámbito global separado. Sin embargo, los tokens almacenados en la memoria se pierden al actualizar la página o al cerrar la pestaña.
• Cookies seguras, HttpOnly (para tokens de actualización y aplicaciones web tradicionales):
  • Para los tokens de actualización, utilice cookies seguras, HttpOnly con un atributo SameSite (Lax o Strict). Las cookies HttpOnly no son accesibles a través de JavaScript del lado del cliente, lo que reduce los vectores de ataque XSS.
  • Para las aplicaciones web tradicionales renderizadas por el servidor, se recomienda almacenar los tokens en el servidor para obtener la máxima seguridad. Si es necesario el almacenamiento del lado del cliente, utilice cookies de sesión cifradas.
• Evite el almacenamiento local y el almacenamiento de sesión: no almacene tokens confidenciales en localStorage o sessionStorage, ya que son vulnerables a los ataques de Cross-Site Scripting (XSS).

2. Aplicaciones móviles (iOS y Android)

• Almacenamiento seguro específico de la plataforma: utilice los mecanismos de almacenamiento seguro del sistema operativo.
  • iOS: utilice Keychain.
  • Android: utilice KeyStore o los datos internos de Android.
  • Estos mecanismos están diseñados para salvaguardar los datos confidenciales y proteger los tokens de otras aplicaciones del dispositivo.

3. Aplicaciones del lado del servidor

• Almacenamiento del lado del servidor: para las aplicaciones en las que el backend realiza llamadas a la API, los tokens deben almacenarse en el servidor. Esto ofrece el máximo nivel de seguridad, ya que los tokens no quedan expuestos al cliente.
• Almacenamiento cifrado: si los tokens deben conservarse, cifrarlos en reposo en la base de datos o el sistema de archivos.

Prácticas recomendadas para la gestión de tokens

• Tokens de actualización: utilizar tokens de actualización para obtener tokens de acceso nuevos y de corta duración sin necesidad de que el usuario vuelva a autenticarse con frecuencia. Los tokens de actualización deben ser de larga duración, almacenarse de forma segura (por ejemplo, cookies HttpOnly) y, a ser posible, rotarse después de su uso.
• Revocación de tokens: Implemente una estrategia para revocar tokens, especialmente tokens de actualización, en casos de compromiso o cierre de sesión del usuario.
• Reclamaciones mínimas: Incluya solo las reclamaciones mínimas necesarias en la carga útil del token para garantizar el rendimiento y la seguridad.
• Desviación del reloj: Al validar reclamaciones basadas en el tiempo (como la caducidad), considere la posibilidad de permitir una pequeña desviación del reloj (unos segundos) para tener en cuenta las pequeñas diferencias horarias entre servidores.
• Patrón Backend for Frontend (BFF): Para las aplicaciones de página única (SPA), considere la posibilidad de utilizar un patrón Backend for Frontend (BFF), en el que el backend se encarga de la adquisición y el almacenamiento de tokens, actuando como intermediario seguro entre la SPA y el servidor de autenticación.