Cómo compartir login y sesión entre microfrontends
Los usuarios inician sesión una vez y esperan que cada parte del producto sepa quiénes son. Eso solo funciona de forma confiable cuando exactamente una pieza de la plataforma es dueña de la autenticación.
Un solo dueño
Exactamente una parte del sistema es dueña del login. En la mayoría de las plataformas es el host, mediante una librería de autenticación que inicializa una sola vez.
Los remotos nunca muestran un formulario de login, nunca ejecutan su propio flujo OAuth y nunca guardan tokens propios.
El flujo habitual
Una configuración común en aplicaciones empresariales es OpenID Connect con el flujo authorization code y PKCE.
- El usuario abre cualquier URL. El host arranca.
- El host revisa si hay sesión. Si no la hay, recuerda la URL pedida y redirige al proveedor de identidad.
- Después del login, el proveedor de identidad redirige de vuelta. El host completa el intercambio del código y regresa a la URL original.
- El host expone el usuario actual a los remotos, que cargan y llaman a sus APIs.
El paso 2 es lo que permite que un deep link sobreviva al login. Mira Rutas entre microfrontends.
Dónde viven los tokens
| Enfoque | Cómo funciona | Pros y contras |
|---|---|---|
| En memoria, administrado por el host | El host guarda el access token en una variable y lo agrega a las peticiones | Simple. El token queda al alcance de los scripts de la página |
| Backend-for-frontend (BFF) | Un componente de servidor guarda los tokens. El navegador solo tiene una cookie de sesión marcada HttpOnly, Secure y SameSite | Los tokens nunca llegan a JavaScript. Necesita un componente de servidor y protección CSRF |
localStorage o sessionStorage | Tokens guardados en el almacenamiento del navegador | Cualquier script puede leerlos, incluido uno inyectado por XSS. Evítalo |
Hay un hecho propio de los microfrontends. Con federation en tiempo de ejecución, cada remoto corre en el mismo contexto de JavaScript que el host. Todo lo que el host puede leer, también lo pueden leer un remoto y sus scripts de terceros. Eso refuerza el argumento a favor del patrón BFF, que las recomendaciones actuales de OAuth para aplicaciones en el navegador describen como la opción más segura. El modelo de amenazas completo está en Seguridad en microfrontends.
Cómo hacen los remotos peticiones autenticadas
- Una capa HTTP compartida. En Angular, el host registra un interceptor HTTP que agrega el token a las peticiones hacia los orígenes de API conocidos. Los remotos que usan el
HttpClientcompartido lo reciben sin hacer nada. - Una función pequeña. Para remotos en otro framework o envueltos como web components, un paquete de plataforma expone algo como
getAccessToken(), que devuelve una promesa. - Con un BFF, nada. La cookie viaja con cada petición al mismo sitio. Los remotos hacen peticiones comunes.
Nunca pases tokens en URLs, en custom events ni en mensajes postMessage abiertos.
Renovación silenciosa
Los access tokens duran poco, así que algo tiene que renovarlos. La renovación va en un solo lugar: el dueño de la autenticación, o el BFF en el servidor.
El problema clásico es la concurrencia. Varias peticiones fallan con 401 al mismo tiempo y cada una intenta renovar. Con refresh tokens rotativos, el segundo intento presenta un token que ya fue usado, y el proveedor de identidad puede revocar toda la sesión. La solución es una sola renovación en curso, con las demás peticiones esperando su resultado.
La renovación con un iframe oculto depende de cookies de terceros, que los navegadores bloquean cada vez más. No diseñes alrededor de esa técnica.
Logout
- El host limpia la sesión y llama al endpoint de cierre de sesión del proveedor de identidad.
- Los remotos deben descartar los datos del usuario que tengan en caché. La forma más confiable es una navegación completa a la pantalla de login, que borra de una vez todo el estado en memoria.
- Las otras pestañas tienen que enterarse. Un mensaje por
BroadcastChannelo un evento de storage permite que cada pestaña reaccione. - La expiración de la sesión se maneja en un solo lugar: el dueño de la autenticación redirige al login y conserva la URL de retorno.
Autorización
El login responde quién es el usuario. Lo que el usuario puede hacer se verifica en tres lugares: el host para el acceso a áreas completas, cada remoto para sus propias pantallas, y la API para todo. Solo la verificación de la API protege los datos.
Errores comunes
- Cada remoto inicializa su propia librería de autenticación. El resultado son varias redirecciones, renovaciones que compiten y un estado de usuario inconsistente.
- La librería de autenticación no es un singleton compartido. Se cargan dos copias, cada una con su estado. Una conoce al usuario y la otra no. Mira Dependencias compartidas y versiones.
- Un remoto registra sus propios providers de cliente HTTP. Sus peticiones se saltan el interceptor del host y salen sin token.
- El logout deja datos en caché en los remotos. El siguiente usuario de un computador compartido los ve.
Checklist
- ¿Hay exactamente un lugar en el código que inicia un login?
- ¿Hay una sola renovación en curso cuando llegan varias respuestas 401 a la vez?
- ¿Un deep link sobrevive a la redirección del login?
- ¿El logout limpia el estado de todos los remotos y de todas las pestañas abiertas?
Más en esta sección
- Cómo se comunican los microfrontends y qué evitar
- Dependencias compartidas y versiones en microfrontends
- Una sola apariencia entre microfrontends: tokens, componentes y aislamiento de estilos
- CI/CD para microfrontends: pipelines independientes, descubrimiento y rollbacks
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn