Al manejar OAuth en una Aplicación de Página Única (SPA), dónde almacenar los tokens de acceso y actualización ha sido un debate de larga data. localStorage, sessionStorage y las variables en memoria son insuficientes frente a XSS. El patrón Backend for Frontend (BFF) es un diseño donde los tokens se mantienen en el lado del servidor en lugar de pasarse al navegador. Este artículo organiza el mecanismo y los puntos clave de implementación.
Requisitos previos
Este artículo asume el siguiente entorno:
- Desarrollo de una aplicación basada en navegador que utiliza OAuth 2.0 y OpenID Connect.
- Existencia de un SPA, las APIs que llama y un servidor de autorización.
- El SPA y sus componentes de servidor de apoyo pueden colocarse en el mismo dominio principal.
- HTTPS es un requisito previo (necesario para emitir Cookies Seguras).
Riesgos de XSS en aplicaciones basadas en navegador
El código de la aplicación que se ejecuta en el navegador es vulnerable a todo lo que ocurre en el entorno de ejecución del navegador. XSS tiene un amplio impacto y, debido a que el código de ataque se ejecuta en el mismo contexto que la aplicación, son posibles las siguientes operaciones:
- Leer valores almacenados en localStorage o sessionStorage.
- Leer variables en memoria accesibles desde JavaScript.
- Ejecutar todas las llamadas a la API que la aplicación puede realizar.
- Cambiar el comportamiento sobrescribiendo funciones integradas (contaminación de prototipos).
Existen múltiples puntos de entrada para XSS, como vulnerabilidades en librerías dependientes, fallos en el procesamiento de entrada/salida del código propio, o el compromiso de scripts de terceros. Dado que es difícil prevenir completamente XSS, una política realista es "limitar el impacto si ocurre una intrusión".
Mientras los tokens estén en el navegador, permanece la posibilidad de que sean robados mediante XSS. Si un atacante utiliza un token de actualización robado en su propio entorno, puede llamar a las APIs durante mucho tiempo incluso después de que el usuario cierre el sitio web. Si bien la rotación de tokens y los tiempos de espera por inactividad pueden mitigar el impacto, no son soluciones fundamentales.
Diseño que no coloca tokens en el navegador
El patrón BFF proporciona un componente del lado del servidor dedicado al SPA y centraliza allí las responsabilidades del cliente OAuth. El SPA no maneja el procesamiento OAuth directamente, sino que realiza la autenticación y las llamadas a la API a través del BFF.
La división de roles es la siguiente:
- Comunicación del protocolo OAuth con el servidor de autorización: manejada por el BFF.
- Almacenamiento de tokens de acceso y actualización: solo el BFF.
- Mantenimiento del estado de autenticación entre el SPA y el BFF: Cookie HttpOnly.
- Llamadas a la API: el SPA envía solicitudes al BFF, y el BFF convierte la Cookie en un token y lo reenvía a la API.
En esta configuración, los tokens solo circulan entre el BFF y las APIs que llama, y son invisibles para el JavaScript del navegador. Incluso si ocurre un XSS, un atacante no puede extraer el token y usarlo desde otro lugar. Todo lo que un atacante puede hacer es enviar solicitudes al BFF dentro del alcance de la sesión que el usuario tiene abierta actualmente. Si bien este impacto no es insignificante, la duración y el alcance del impacto se limitan significativamente en comparación con el robo de tokens.
El BFF actúa como lo que la terminología OAuth denomina un "cliente confidencial". Posee un secreto de cliente y completa el intercambio de códigos de autorización por tokens y el procesamiento de actualización completamente en el lado del servidor.
Flujo de autenticación
Un flujo de autenticación típico es el siguiente:
- Cuando el SPA inicia un inicio de sesión, envía una solicitud de inicio de sesión al BFF.
- El BFF inicia un flujo de código de autorización con PKCE, genera una URL de redirección al servidor de autorización y la devuelve al SPA.
- El SPA redirige el navegador a esa URL, y el usuario se autentica en el servidor de autorización.
- El servidor de autorización devuelve un código de autorización a la URI de redirección del BFF.
- El BFF intercambia el código de autorización por tokens y obtiene un token de acceso y un token de actualización.
- El BFF almacena los tokens en su propia área segura (cookie cifrada, almacén de sesión del lado del servidor, etc.) y devuelve solo un identificador de sesión al SPA mediante una Cookie HttpOnly.
- Cuando el SPA llama a una API, envía la solicitud a través del BFF. La Cookie se envía simultáneamente, y el BFF la convierte en un token de acceso y lo reenvía a la API ascendente.
- Si el token de acceso expira, el BFF lo actualiza silenciosamente utilizando el token de actualización.
Desde la perspectiva del SPA, el estado de inicio de sesión se mantiene mediante la Cookie, y las solicitudes a la API se completan con llamadas fetch normales. En el SPA no existe código que maneje directamente tokens OAuth o códigos de autorización.
Configuraciones de seguridad requeridas
Se deben establecer los siguientes atributos para la Cookie emitida por el BFF:
- HttpOnly: Prohíbe el acceso desde JavaScript. Incluso con XSS, no se puede leer el contenido de la Cookie.
- Secure: Se envía solo a través de HTTPS.
- SameSite=Strict: Asegura que la Cookie no se envíe con solicitudes de otros sitios. Esto ayuda a bloquear las principales vías de ataque CSRF, pero la protección CSRF no se completa solo con esto.
- Prefijo __Host-: Agregar el prefijo __Host- al nombre de la Cookie asegura que el navegador limite la Cookie al host emisor y no la comparta con subdominios.
Si se almacenan tokens en una Cookie cifrada (sesión del lado del cliente), el contenido de la Cookie está cifrado. Si se colocan tokens en un almacén de sesión del lado del servidor (sesión del lado del servidor), la Cookie solo contiene un identificador de sesión, por lo que no es necesario el cifrado.
La protección CSRF no debe depender únicamente de SameSite
Dado que utiliza autenticación basada en Cookies, el BFF debe implementar protección contra CSRF. SameSite=Strict es un paso válido, pero no es la solución completa. Se necesita precaución especialmente en configuraciones donde el SPA se coloca en www.ejemplo.com y el BFF en api.ejemplo.com. Dado que la determinación de SameSite se realiza por sitio en lugar de por origen, las solicitudes de otros subdominios bajo ejemplo.com se consideran "mismo sitio", y las Cookies se enviarán incluso con SameSite=Strict.
Por lo tanto, refuerce la defensa CSRF con una de las siguientes opciones:
- Si el BFF y el SPA están en orígenes diferentes, use CORS y la validación del encabezado Origin para la defensa.
- Para solicitudes que cambian el estado, verifique los tokens CSRF utilizando el método anti-falsificación / cookie de doble envío.
Limite CORS a orígenes exactos
CORS debe permitirse solo para el origen exacto del SPA. Para solicitudes con credenciales que involucran Cookies, los navegadores no permiten comodines (*) en Access-Control-Allow-Origin. Por lo tanto, el BFF debe reflejar el origen exacto del SPA en la respuesta. Esta limitación estricta de los orígenes permitidos funciona como parte de la defensa CSRF.
Se requiere gestión de claves para los datos de sesión que posee el BFF, especialmente la información de tokens almacenada en Cookies cifradas. Incorpore operaciones para inyectar claves de forma segura como configuración del BFF y rotarlas regularmente.
Tenga en cuenta que colocar el SPA y el BFF en el mismo dominio principal es para cumplir la condición de que las Cookies Same-Site funcionen como Cookies de primera parte.
Evolución: BFF impulsado por API
Si un BFF se construye como una aplicación web tradicional, la representación del lado del servidor del BFF se involucra en las transiciones de página del SPA. Un BFF impulsado por API minimiza este impacto.
Los roles se dividen en dos:
- Agente OAuth: Una API responsable del procesamiento del protocolo OAuth. El SPA la llama mediante JSON.
- Proxy OAuth: Opera como un complemento de puerta de enlace de API, extrae el token de la Cookie y lo reenvía a la API ascendente.
En esta configuración, el SPA simplemente llama al Agente OAuth como una API REST normal. La experiencia de desarrollo del frontend del SPA puede mantenerse casi igual que antes de introducir el BFF.
Consideraciones para la adopción
Al adoptar el patrón BFF, considere lo siguiente:
- Los componentes arquitectónicos adicionales aumentan los costos de desarrollo y operación.
- El SPA y el BFF deben colocarse en el mismo dominio principal.
- Una configuración que simplemente reenvíe el encabezado Authorization a través de un proxy inverso no es un BFF. La esencia de un BFF es mantener el token como un cliente confidencial.
- PKCE y BFF se usan juntos, no como alternativas.
- El BFF debe verificar el host de destino antes de reenviar para evitar la exposición del token a hosts no deseados.
- El diseño del cierre de sesión se vuelve complejo, ya que deben vincularse las sesiones del SPA, las cookies del BFF y las sesiones del servidor de autorización.
Resumen
Una forma práctica de manejar tokens de forma segura en aplicaciones basadas en navegador es no colocarlos en el navegador. El patrón BFF traslada las responsabilidades del cliente OAuth al lado del servidor y pasa solo Cookies HttpOnly al navegador. Esto evita el robo de tokens incluso si ocurre un XSS. Al dividir los roles en un Agente OAuth y un Proxy OAuth, se puede fortalecer la seguridad mientras se mantiene la experiencia de desarrollo del SPA.
