Resumen

  • El Backend for Frontend de RFC 10017 actúa como cliente OAuth confidencial, conserva los tokens de acceso y renovación en el contexto de una sesión con cookie y agrega el token correcto a cada llamada saliente. El navegador no dispone de un token que robar ni de las credenciales necesarias para canjear por sí solo un código nuevo.
  • Código malicioso ejecutado en el origen legítimo todavía puede enviar al BFF una petición que la aplicación sabe formular. El navegador aporta la cookie y el BFF ejecuta la traducción. El resultado es secuestro del cliente: menos autónomo que robar el token, pero limitado únicamente por las acciones realmente expuestas.
  • El recibo verificable une origen y versión del frontend, sesión y política de cookies, resultado CSRF, endpoint, destino/ruta/método permitidos, audience y scopes, decisión del servidor de recursos, transformación de respuesta, anomalía y reparación.

El hallazgo más incómodo de una prueba de intrusión puede redactarse así: «Los tokens estaban correctamente protegidos; la operación no».

El equipo comprueba que localStorage está limpio, que la cookie es HttpOnly y que el refresh token solo existe en el servidor. Aun así, el script inyectado solicita una exportación, cambia una preferencia de seguridad o ejecuta otra acción válida. No ha robado una credencial. Ha utilizado la aplicación mientras la credencial funcionaba detrás de ella.

La RFC 10017 llama a este resultado client hijacking y lo separa del robo de tokens. Publicada en agosto de 2026 como Best Current Practice del IETF, OAuth 2.0 for Browser-Based Applications lleva los nombres de Aaron Parecki, Philippe De Ryck y David Waite. El registro oficial del IETF guardado el 31 de agosto de 2026 presenta a Parecki como copresidente de SCIM y enumera dos RFC, incluida esta. Su propio sitio documenta su función en estándares de identidad, el mantenimiento de oauth.net y su participación en el grupo OAuth del IETF.

La atribución es relevante y acotada. No convierte un trabajo colectivo en invención individual ni certifica implementaciones. Cada operador decide con código y configuración cuánta autoridad conserva la sesión.

El modelo empieza con el atacante dentro del origen

La pregunta habitual «¿dónde guardamos el token?» presupone que quien ejecuta el código es la aplicación. RFC 10017 analiza la condición posterior: una vulnerabilidad XSS, un recurso remoto comprometido u otra vía permite ejecutar JavaScript o WebAssembly hostil en el contexto de la aplicación.

Ese código hereda los privilegios del origen. Lee todo almacenamiento accesible, invoca funciones, altera el flujo, inspecciona contextos del mismo origen y llama al backend. Codificación contextual, control de terceros, Subresource Integrity, una CSP robusta y aislamiento siguen siendo imprescindibles porque evitar esa ejecución es la única forma de evitar por completo el secuestro del cliente.

Cuando la prevención falla, la RFC distingue cuatro conductas. El atacante puede copiar los tokens actuales una vez; puede instalar una captura persistente; puede lanzar un nuevo flujo y extraer tokens independientes; o puede no extraer nada y mandar solicitudes desde el navegador. La última vía aprovecha que el navegador o un componente auxiliar adjunta automáticamente el elemento de autorización.

Por eso una clave no exportable o una cookie ilegible no equivale a una acción no invocable. El diseño puede impedir que la autoridad viaje a otro equipo y, al mismo tiempo, permitir que se ejerza dentro de la sesión abierta.

El BFF elimina autoridad portátil

RFC 10017 ordena sus tres arquitecturas principales de mayor a menor seguridad. El BFF ocupa la primera posición y se recomienda con fuerza para aplicaciones empresariales, sensibles y que procesan datos personales. Su componente servidor es el cliente OAuth confidencial, completa Authorization Code con PKCE, mantiene los tokens y canaliza todas las interacciones con recursos.

Hay dos vínculos y no uno. El authorization server entrega tokens al BFF. El BFF crea después una sesión con el navegador mediante una cookie. Para acceder a un recurso, el frontend llama al BFF; este resuelve la sesión, elimina la cookie de la llamada saliente, adjunta el access token y contacta al resource server.

La ganancia es concreta. JavaScript no puede exfiltrar el token actual ni capturar cada rotación. Un código de autorización obtenido en un frame no basta para ejecutar el canje, porque el atacante carece de las credenciales del cliente confidencial. PKCE protege además la transacción del código. HttpOnly impide leer la sesión directamente y evita que el secuestro del cliente se transforme automáticamente en una sesión exportable.

Lo que persiste es la capacidad de llamar a los endpoints permitidos mientras el código hostil opera en el origen y la sesión sigue activa. El BFF no afirma conocer cuál de dos scripts con los mismos privilegios expresa la intención humana. Su promesa es más estrecha y más defendible: no entregar al navegador un bearer token reutilizable por separado.

El mapa de salida es parte de la autorización

En el lado del navegador entra cookie; en el lado del recurso sale token. El BFF traduce entre ambas formas. Si la URL de salida queda bajo control de la entrada, ese traductor puede revelar el token a un host del atacante.

La RFC exige validar los destinos, mantener una allowlist explícita de servidores de recursos y restringir con rigor rutas dinámicas. También propone limitar métodos por endpoint. Un endpoint de lectura no debería poder reenviar POST o DELETE solo porque la solicitud entrante los incluye.

El host no agota la política. Una API puede compartir dominio con operaciones administrativas. Un parámetro puede introducir una URL. Un redirect puede abandonar el destino inicialmente aprobado. El conjunto operativo necesita scheme, host, plantilla de ruta, método, esquema del cuerpo, política de redirects, token audience, scopes y clase de respuesta.

El servidor de recursos conserva la última autorización. Debe comprobar issuer, audience, expiración y permisos, y decidir si ese sujeto puede actuar sobre ese objeto. Un token amplio y un proxy genérico multiplican el alcance del secuestro; rutas estrechas y autorización por objeto lo reducen. La sesión identifica una relación con el cliente, no una voluntad universal del usuario.

Aquí se ve la utilidad de una especificación inicial mínima. El estándar común fija cliente confidencial, cookie protegida, CSRF y proxy acotado. El operador local aporta el mapa que el estándar no puede conocer. Usar la etiqueta BFF sin ese mapa convierte interoperabilidad en opacidad.

La cookie separa identidades, no intenciones

RFC 10017 obliga a activar Secure y HttpOnly, y aconseja SameSite=Strict, path /, no declarar Domain y emplear un prefijo HTTP como __Host-Http- cuando corresponda. Si una sesión de cliente contiene tokens, debe cifrarse para no dejar material en claro en el almacenamiento persistente.

Cada medida evita un fallo distinto: lectura desde script, transporte inseguro, exposición a subdominios o lectura de disco. Ninguna demuestra que la petición fue deseada por la persona.

La cookie también exige defensa CSRF. SameSite=Strict no resuelve todos los casos porque dos subdominios pueden ser same-site y cross-origin. El control de un subdominio hermano abre un camino de falsificación contra otro.

CORS sirve cuando fuerza preflight. Las solicitudes safelisted pueden salir aunque el navegador impida después leer la respuesta. La RFC recomienda un header personalizado y, si se adopta, exige verificarlo en cada petición. Un mecanismo anti-forgery o double-submit del framework ofrece otra alternativa.

CSRF separa origen externo y origen legítimo. El JavaScript malicioso del mismo origen ya está del lado que supera esa separación. Por eso aprobar CSRF no equivale a comprobar intención ni puede ser el único registro de autorización.

El riesgo residual tiene tamaño medible

El secuestro del cliente es menos potente que poseer directamente el token. El atacante depende del navegador, de la sesión y de los controles que el cliente y el recurso mantengan. Puede encontrar una ruta bloqueada por CORS, no expuesta por el BFF o denegada por autorización de objeto. RFC 10017 conserva expresamente esta diferencia.

La organización debe demostrarla con un inventario ejecutable: endpoint BFF, host, ruta, método, token, audience, scopes, regla de objeto y datos de respuesta. La prueba relevante introduce código hostil en el origen de manera controlada e intenta salir de cada combinación, no se limita a confirmar el login normal.

El BFF observa todo el tráfico que media. Puede detectar ráfagas incompatibles con interacción humana, secuencias raras de endpoints, acceso a un conjunto atípico de objetos o una sesión activa después de invalidarse el refresh token. La RFC lo identifica como un lugar idóneo para anomaly detection y rate limiting.

Esa centralidad también concentra información. Un BFF alojado por un tercero puede ver todas las solicitudes y respuestas. Minimización, retención, separación entre clientes y acceso del operador forman parte del mismo contrato. Reducir la exposición del navegador no autoriza una observación ilimitada.

La sesión debe terminar cuando termina la autoridad que representa. La RFC recomienda alinear su duración máxima con la del refresh token e invalidarla cuando este deja de ser válido. Las sesiones de servidor dan revocación directa pero cuestan estado y replicación; las de cliente escalan mejor pero dependen de expiración y revocación de tokens.

Construir el recibo de extremo a extremo

No registrar el token, el secret ni la cookie completa. Esos datos convertirían la auditoría en otra fuga.

Para cada operación sensible, conservar un identificador no reutilizable de sesión, creación y vencimiento, política de cookies, evento de autenticación, transacción de código, identidad del cliente BFF y build del frontend. Añadir endpoint, método, plantilla de ruta, resultado CSRF/origin/CORS y validación de la estructura recibida.

Registrar después la traducción: resource server, ruta y método salientes, versión de allowlist, fingerprint no secreto del token, issuer, audience, scopes y vencimiento; si afecta a la petición, rotación, renovación, revocación o invalidación. Completar con la decisión del resource server, estado, transformación de respuesta, rate limit/anomalía, dueño del cambio y remedio.

Así el incidente recibe nombre correcto. Exfiltración de token, robo de sesión, CSRF, ejecución hostil same-origin, open proxy y permisos downstream excesivos tienen responsables y correcciones diferentes.

Running-Code Primacy cierra el ciclo: ejecutar un script controlado en el origen y demostrar que no lee credenciales, no crea un flujo independiente, no sale del host/path/method aprobado, no supera derechos de objeto y genera alerta cuando usa de manera anómala una acción técnicamente permitida.

El BFF cumple cuando el token no puede salir y la autoridad restante queda limitada, observable y revocable.

Fuentes