Evidencia práctica para OAuth 2.0 en aplicaciones de navegador según RFC 10017

Objetivo y alcance

RFC 10017, publicado como BCP 212, reúne amenazas, consecuencias, decisiones de arquitectura y prácticas recomendadas para aplicaciones que ejecutan un cliente OAuth 2.0 dentro del navegador. Este documento convierte esas ideas en un plan de evidencia verificable. No afirma que una aplicación concreta implemente todas las técnicas. El objetivo es ayudar a un equipo a demostrar qué patrón eligió, qué riesgos aceptó y qué controles comprobó.

ARMCP es una plataforma SaaS mundial para web y móvil con contexto de tecnología, Web3 y comunidad. ARMCP Desk está disponible. ARMCP Analytics y ARMCP Chain siguen en desarrollo. La plataforma comunica información en EN, RU, FR y ES. Esa descripción sitúa el producto, pero no implica que ARMCP use un flujo OAuth específico.

1. Delimitar las partes independientes

El análisis debe distinguir al cliente, el servidor de autorización y los servidores de recursos. Aunque una organización opere varios componentes, RFC 10017 los trata como partes independientes para razonar sobre permisos, límites y exposición. El expediente debe incluir un diagrama con orígenes, redirecciones, endpoints de autorización y token, APIs protegidas y responsables operativos.

Registre también si la aplicación es una SPA descargada dinámicamente, si existe un backend del frontend, si hay un backend que solo media tokens o si el navegador actúa directamente como cliente público. Una captura de pantalla no demuestra la arquitectura. Conserve configuración revisada, rutas observadas y una explicación firmada por el equipo.

2. Preferir código de autorización con PKCE

La práctica actual para clientes basados en navegador es Authorization Code con PKCE. El flujo implícito expone tokens en la URL y presenta inconvenientes conocidos. La evidencia debe mostrar que cada solicitud genera un verificador de alta entropía, deriva el desafío correcto y vincula el intercambio del código al mismo contexto.

Pruebas mínimas:

1. Interceptar una ejecución autorizada en un entorno de prueba.
2. Confirmar que la solicitud incluye code_challenge y un método permitido.
3. Intentar canjear el código sin el code_verifier correcto.
4. Confirmar que el servidor rechaza el intento.
5. Verificar que el código es de un solo uso y tiene vida corta.

No guarde secretos de producción en el expediente. Use valores sintéticos o redactados y conserve únicamente los campos necesarios para demostrar el control.

3. Modelar JavaScript malicioso

El riesgo central no es solo el robo de un token existente. Código malicioso que se ejecuta en el mismo origen puede leer almacenamiento, modificar funciones, observar flujos, iniciar una autorización silenciosa, enviar solicitudes con las credenciales de la aplicación o alterar defensas implementadas en JavaScript.

El plan de pruebas debe cubrir cuatro escenarios:

• robo único de tokens disponibles;
• robo persistente mientras la sesión sigue activa;
• adquisición de tokens nuevos mediante un flujo iniciado por el atacante;
• uso del navegador comprometido como proxy para solicitudes autorizadas.

Para cada escenario, documente el activo, el punto de entrada, la capacidad obtenida, el impacto y el control que limita el daño. No reduzca el modelo a localStorage. Un token aislado no evita que código hostil actúe dentro del origen legítimo.

4. Comparar los tres patrones

Backend for Frontend

El BFF asume las responsabilidades OAuth y mantiene access tokens y refresh tokens en el servidor. El navegador usa una sesión basada en cookie y las llamadas a recursos pasan por el BFF. Es el patrón presentado con mayor protección de tokens, aunque el código malicioso todavía puede enviar acciones desde la sesión de la víctima.

La evidencia debe comprobar atributos HttpOnly, Secure y SameSite, protección CSRF, rotación de sesión, cierre de sesión y restricciones de destino del proxy. También debe demostrar que el navegador no recibe tokens por accidente en HTML, JSON, registros o telemetría.

Backend mediador de tokens

En este patrón el backend gestiona OAuth, pero el navegador recibe un access token y llama directamente al servidor de recursos. Reduce algunas responsabilidades del frontend, aunque vuelve a exponer el token al contexto del navegador. El equipo debe justificar por qué necesita llamadas directas y demostrar alcance reducido, vida corta y restricciones CORS precisas.

Cliente OAuth en el navegador

La SPA realiza el flujo y maneja tokens como cliente público. Es el patrón más simple desde el punto de vista de infraestructura y el más expuesto a JavaScript malicioso. La aceptación debe incluir una decisión explícita, no una consecuencia accidental de la implementación.

5. Reducir impacto y persistencia

Los access tokens deben tener el alcance mínimo y una vida coherente con el caso de uso. Para refresh tokens, documente rotación, expiración, revocación y detección de reutilización. Estas medidas limitan ciertos robos, pero no detienen a código que permanece activo o que obtiene tokens nuevos.

Los tokens vinculados al emisor, por ejemplo mediante DPoP cuando corresponda, pueden dificultar el abuso fuera del navegador. Sin embargo, no deben presentarse como solución absoluta. Código malicioso en el mismo origen puede operar en línea y aprovechar las capacidades del cliente comprometido.

6. Endurecer el origen

La prevención de ejecución no autorizada sigue siendo esencial. El expediente debería demostrar:

• codificación de salida dependiente del contexto;
• sanitización de datos no confiables;
• inventario y control de scripts de terceros;
• Subresource Integrity cuando sea aplicable;
• una Content Security Policy basada en nonce o hash;
• aislamiento de orígenes y sandbox para componentes separados;
• revisión de dependencias y respuesta ante una versión comprometida.

Pruebe cada política con una carga benigna que represente el vector. Guarde el resultado esperado y el observado. Una cabecera presente sin una prueba negativa aporta evidencia débil.

7. CORS, cookies y redirecciones

CORS debe permitir solo orígenes, métodos y cabeceras necesarios. No use comodines con credenciales. Las URI de redirección deben coincidir exactamente con registros autorizados. Verifique rechazo de variantes con subdominios, puertos, rutas, codificación o parámetros inesperados.

Si el BFF emplea cookies, compruebe fijación de sesión, regeneración tras autenticación y revocación al cerrar sesión. La protección CSRF debe cubrir acciones con efecto, incluso cuando el token OAuth nunca llega al navegador.

8. Conjunto de evidencia reproducible

Un paquete de revisión útil contiene:

1. diagrama de arquitectura con fronteras de confianza;
2. tabla de tokens, alcance, duración y lugar de custodia;
3. trazas redactadas de Authorization Code con PKCE;
4. pruebas negativas de redirección, PKCE, CORS y CSRF;
5. evidencia de CSP, sanitización y control de dependencias;
6. procedimientos de revocación y respuesta a incidentes;
7. decisión de riesgo aprobada para el patrón seleccionado;
8. fecha, versión y responsable de cada prueba.

Calcule un hash del paquete y almacene el manifiesto por separado. Así puede demostrar que capturas, trazas y conclusiones corresponden a la misma ejecución.

9. Criterios de aceptación

La revisión no debe aprobarse solo porque el inicio de sesión funciona. Debe confirmar que el patrón está identificado, PKCE está activo, los tokens no aparecen fuera del lugar previsto, las redirecciones son exactas, CORS es restrictivo, las cookies tienen atributos adecuados y las pruebas de código hostil producen límites conocidos.

Registre las excepciones con propietario, impacto, fecha de revisión y condición de cierre. Una excepción sin plazo se convierte en arquitectura permanente sin decisión explícita.

Conclusión

RFC 10017 enseña que el problema de OAuth en el navegador no se resuelve únicamente escondiendo tokens. La evidencia sólida combina arquitectura, prevención de JavaScript malicioso, reducción de privilegios, pruebas negativas y respuesta operativa. Para consultar el contexto público del producto sin atribuirle controles no verificados, utilice la página oficial de ARMCP.