Prevención de condiciones de carrera en aplicaciones de página única con PKCE y okta-auth-js en múltiples pestañas

Las aplicaciones de página única (SPA) que utilizan la autenticación basada en Proof Key for Code Exchange (PKCE) a menudo enfrentan problemas ocultos de concurrencia al ejecutarse en múltiples pestañas del navegador. Aunque bibliotecas como okta-auth-js admiten la sincronización del almacenamiento local y la renovación automatizada, las configuraciones predeterminadas carecen de límites transaccionales entre pestañas. Debido a que cada pestaña ejecuta su propia instancia del SDK sobre un almacenamiento compartido, con frecuencia se activan solicitudes simultáneas de renovación de tokens, lo que arriesga corromper el estado de sesión activo.

Límites de concurrencia en la configuración estándar del SDK

Una configuración estándar de okta-auth-js habilita controladores de eventos de almacenamiento y temporizadores de expiración automatizados en todas las pestañas. Sin embargo, el almacenamiento local compartido no proporciona exclusión mutua para las solicitudes de red. Cuando los temporizadores se activan, cada pestaña abierta intenta renovar los tokens al mismo tiempo. Los inicios de sesión no coordinados también pueden desencadenar ciclos redundantes de autorización, mientras que la eliminación indiscriminada del almacenamiento destruye los verificadores de código PKCE activos e interrumpe los procesos de inicio de sesión en curso en otras pestañas.

Coordinación de renovaciones con la API Web Locks

Para eliminar las condiciones de carrera de los tokens, las aplicaciones pueden implementar un mecanismo de elección de líder mediante la API Web Locks. Elegir una sola pestaña líder para las renovaciones garantiza que únicamente dicha instancia ejecute la solicitud de red durante un ciclo de renovación, mientras que las pestañas seguidoras esperan la llegada de credenciales actualizadas a través de eventos de almacenamiento. El líder elegido debe volver a verificar el almacenamiento dentro del bloqueo antes de realizar la llamada a la red para comprobar si un titular anterior del bloqueo ya completó la renovación. Adicionalmente, las aplicaciones deben restringir las actualizaciones de tokens a los documentos visibles, evitando que las pestañas congeladas o en segundo plano detengan las solicitudes.

Gestión de tokens y configuración del proveedor de identidad

La distribución adecuada del estado requiere canalizar todas las actualizaciones de credenciales mediante tokenManager.setTokens() para que los eventos de almacenamiento se emitan de forma confiable entre documentos. Los desarrolladores deben obtener tokens en el punto de uso con getIdToken() o getAccessToken() en lugar de confiar en el estado almacenado en caché de los componentes de la interfaz. En el lado del proveedor de identidad, configurar un período de gracia de rotación de tokens superior a la ventana de transferencia del bloqueo entre pestañas y definir una ventana de inactividad de al menos tres veces la duración del token de acceso evita la finalización prematura de la sesión. Si ocurre un error invalid_grant, las aplicaciones deben consultar el almacenamiento una vez más antes de declarar un fallo de autenticación.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: Multi-Tab Session Sync in a PKCE SPA with `okta-auth-js`