Resumen

  • RFC 10017, publicado en agosto de 2026 como una mejor práctica vigente del IETF, recomienda con especial fuerza un Backend for Frontend para aplicaciones empresariales, sensibles o que tratan datos personales, porque mantiene los tokens OAuth fuera del navegador.
  • Esa arquitectura reduce el robo puntual o persistente de tokens y la obtención de credenciales nuevas, pero no impide que código malicioso dentro del mismo origen envíe peticiones respaldadas por la cookie. Demostrar custodia no demuestra intención.

Un incidente sin credenciales ausentes

La escena inicial es una construcción analítica, no el relato de una intrusión publicada. Sirve para separar dos preguntas que suelen fundirse durante una respuesta a incidentes. La primera es dónde estuvieron los secretos. La segunda es qué acciones pudo ordenar el contexto autenticado. Una respuesta correcta a la primera no clausura la segunda.

RFC 10017 parte de una realidad incómoda del navegador: cuando JavaScript malicioso se ejecuta en el origen de la aplicación, disfruta de las mismas facultades prácticas que el código legítimo. Puede observar datos de la página, usar almacenamiento asociado al origen, comunicarse con otros contextos del mismo origen y enviar solicitudes al backend. No necesita copiar una cadena secreta si la infraestructura ya está dispuesta a usarla por cuenta de cualquier código admitido en ese contexto.

El documento distingue cuatro situaciones relevantes para OAuth. Puede producirse el robo único de tokens existentes, una extracción persistente a medida que rotan, la adquisición de tokens nuevos mediante otro flujo de autorización o el uso del navegador como intermediario para enviar peticiones. La cuarta posibilidad explica por qué un inventario de secretos intactos puede convivir con una operación no deseada.

Desde el BFF, una petición inducida por una dependencia comprometida puede parecer idéntica a la generada por un clic auténtico. Ambas llegan desde el origen esperado y ambas llevan la sesión que el navegador adjunta. Si el BFF agrega después el token de acceso, también lo agregará a la petición provocada por el atacante, salvo que otra política distinga la acción.

Por eso «no hubo exfiltración» debe conservar un alcance limitado. Permite afirmar que el valor portador no salió de custodia y que no quedó disponible para repetición desde otro equipo. No permite afirmar que la sesión no ejecutó una orden, que el mapa de rutas era correcto ni que el servicio de recursos debía aceptar el efecto empresarial.

El BFF cambia las consecuencias, no vuelve confiable al origen

Un Backend for Frontend actúa como cliente OAuth confidencial. Conserva los tokens de acceso y actualización en el servidor, mantiene una sesión para el navegador y reenvía solicitudes a los servicios de recursos después de elegir la credencial adecuada. El frontend opera con una interfaz de sesión, no con el material de los tokens.

La mejora es sustancial. El código comprometido no encuentra un token de acceso que copiar, no puede observar la rotación del token de actualización y no debería canjear por sí solo un código nuevo sin las credenciales confidenciales del BFF. RFC 10017 considera que esta combinación mitiga los tres primeros escenarios y la recomienda especialmente cuando las consecuencias comerciales, personales o regulatorias son altas.

El cuarto escenario sobrevive. El código hostil todavía puede llamar al BFF desde el navegador del usuario. La cookie HttpOnly no es visible para JavaScript, pero el navegador puede incluirla automáticamente en una solicitud permitida. Entonces el BFF recupera la sesión, selecciona un token y cursa la operación. Ningún secreto se revela durante el recorrido.

La seguridad obtenida consiste en limitar el ataque a lo que esa sesión, esas rutas y las políticas del servicio permiten. Evita que una toma del cliente se convierta automáticamente en una credencial portátil de larga vida. No convierte en sujeto independiente y confiable cada fragmento de código que comparte el origen.

Esta comparación evita dos extremos. Sería erróneo minimizar el BFF porque no elimina toda acción hostil; también sería erróneo presentarlo como prueba completa de autorización. Su valor está en reducir la duración, movilidad y alcance del daño, mientras deja otras decisiones a controles de solicitud y negocio.

Una cookie ilegible sigue siendo una autoridad activa

El BCP exige Secure y HttpOnly para las cookies del BFF. Además, recomienda SameSite=Strict, ruta /, ausencia del atributo Domain y un prefijo ligado al host cuando el despliegue lo permita. Son límites concretos frente a lectura por scripts, exposición en transporte y distribución excesiva entre subdominios.

Ninguno prueba que el usuario pretendiera la petición. Las interacciones respaldadas por cookie necesitan una defensa CSRF completa. SameSite ayuda, pero los subdominios hermanos pueden ser del mismo sitio aun cuando sean orígenes distintos. Una toma de control en uno de ellos puede crear un camino que una auditoría basada solo en la etiqueta SameSite no detecte.

CORS tampoco debe resumirse con una casilla. Algunas solicitudes consideradas seguras por el protocolo se envían sin preflight; el navegador puede limitar la lectura de la respuesta sin impedir el efecto. Un BFF puede exigir un encabezado personalizado para forzar esa comprobación, pero la evidencia debe demostrar que todos los endpoints sensibles rechazan solicitudes que no lo contienen.

Los relojes importan. El vencimiento de la sesión del navegador, del token de actualización y de las autorizaciones de recursos debe poder correlacionarse. Si una sesión parece viva después de que la credencial subyacente ya no puede renovarse, el usuario y los operadores reciben señales contradictorias. Si se revoca el token sin identificar las sesiones afectadas, la organización no sabe qué capacidad quedó realmente detenida.

La disciplina útil consiste en registrar emisión, renovación, expiración y revocación como decisiones relacionadas, no como eventos aislados. Una cookie protegida sigue siendo un mecanismo que gasta autoridad mientras sea aceptada.

El mapa del proxy también autoriza

Un BFF no es solamente una caja fuerte para secretos. Traduce una solicitud entrante autenticada por cookie en una llamada saliente autorizada por un token portador. La selección de destino, ruta y método define qué puede ordenar la sesión.

RFC 10017 exige controles salientes estrictos. Los hosts deben pertenecer a una lista permitida; los segmentos dinámicos de ruta requieren validación; los métodos pueden limitarse para cada operación. Un proxy abierto o excesivamente dinámico puede enviar un token válido a un host equivocado o exponer una operación que la interfaz nunca pretendió ofrecer.

La ruta /bff/pedidos/{id}, por ejemplo, encierra una decisión. No basta con que resuelva hacia el servicio esperado. Hay que decidir si admite lectura, cancelación, reembolso o modificación; quién puede actuar sobre ese identificador; y qué condiciones comerciales siguen vigentes. El servicio de recursos conserva la obligación de validar audiencia, alcance, sujeto y política de la acción.

El resultado observado completa la evidencia. Una respuesta HTTP favorable del BFF no garantiza que la operación haya quedado firme; el backend puede resolverla después. También puede haber reintentos, duplicados o límites de tasa distorsionados porque muchos usuarios comparten una dirección de salida. Identificador de solicitud, sesión, decisión de ruta, audiencia del token, fallo o aceptación del recurso y estado final deben unirse en una misma cronología.

La privacidad se desplaza junto con la custodia. El BFF ve solicitudes y respuestas entre navegador y recursos. Si un tercero lo opera, disminuye la exposición de tokens en el cliente, pero aumenta la visibilidad centralizada de datos y conductas. Son beneficios y costes distintos; ninguno debe ocultarse bajo la etiqueta genérica de «más seguro».

Tres arquitecturas, tres rastros probatorios

El documento compara un BFF completo, un backend mediador de tokens y un cliente OAuth que funciona solo en el navegador. En el primero, acceso y actualización permanecen en el servidor y todas las llamadas pasan por el proxy. En el segundo, el backend guarda las credenciales confidenciales y el token de actualización, pero entrega tokens de acceso al navegador. En el tercero, el cliente público gestiona el flujo y los tokens en el propio runtime.

El mediador reduce la posibilidad de robar la capacidad de renovación y de completar un nuevo canje, pero un token de acceso vuelve a estar disponible para el código del navegador. Persisten su extracción y su uso inmediato. No es un BFF incompleto; es una distribución diferente de consecuencias y de pruebas disponibles.

El cliente solo de navegador queda expuesto a los cuatro escenarios. Debe usar Authorization Code con PKCE, y sus tokens de actualización tienen que rotar o estar vinculados criptográficamente al emisor, además de contar con una vida máxima o de inactividad. Estas medidas reducen intercepción y persistencia; no aíslan código hostil que ya comparte el origen.

DPoP también ofrece un límite útil. Un token ligado a una clave no exportable puede ser difícil de reutilizar lejos del dispositivo. Sin embargo, el código comprometido puede seguir haciendo que el navegador envíe peticiones y, cuando puede iniciar un flujo nuevo, intentar vincularlo a una clave bajo su control. La expresión «ligado al emisor» requiere indicar qué emisor, qué clave y qué flujo se observaron.

Tampoco toda aplicación bajo un dominio común necesita OAuth entre frontend y API. Cuando ambos pertenecen a la misma aplicación y no existe un recurso independiente, la autenticación federada puede desembocar en una sesión propia. Añadir OAuth sin una frontera real puede sumar tokens y proxies sin crear una separación de autoridad.

La afirmación debe ser tan estrecha como el control

RFC 10017 resulta útil porque no presenta el navegador como un enclave. Ordena amenazas y asigna mecanismos a consecuencias concretas. El BFF es una respuesta fuerte al problema de custodia de tokens; no declara confiable todo el código del origen ni prueba que cada petición refleje la voluntad del usuario.

Una revisión defendible conserva la procedencia del código y sus dependencias, el origen, la emisión y expiración de la sesión, los atributos de cookie, la hora, método, ruta y clase del cuerpo, el resultado CSRF, la regla CORS, el mapeo del BFF, la audiencia y alcance del token, la decisión del recurso, la respuesta, el efecto final y el responsable de revertirlo. Cada elemento tiene reloj y dueño propios.

Ese registro también protege una coordinación delgada. El estándar compartido fija un mínimo y describe opciones; el equipo local mantiene la responsabilidad sobre rutas, dependencias, umbrales, reversibilidad y consecuencias. El código que corre y las peticiones que realmente cruzan la frontera pesan más que un diagrama rotulado BFF.

La organización que soporta fraude, pérdida de privacidad o indisponibilidad debe conservar la decisión final sobre qué acción admite, observa, detiene y revierte. Mantener los tokens en el servidor es una condición valiosa. Mantener estrecha la autoridad de la sesión es la segunda mitad del trabajo.

Fuentes