Los scopes OAuth opcionales de Cloudflare hacen más limitado el consentimiento, no lo vuelven seguro automáticamente

Cloudflare permite ahora rechazar permisos OAuth opcionales al autorizar Wrangler o el servidor Model Context Protocol (MCP) de la API de Cloudflare. El token de acceso contiene únicamente los scopes que el usuario aprobó. Es un control útil de mínimo privilegio, sobre todo cuando un cliente de agente puede invocar herramientas que van más allá de la tarea que tiene delante.

No es un mínimo privilegio automático. Cloudflare sigue seleccionando por defecto el conjunto completo solicitado, los scopes obligatorios no se pueden desactivar durante el consentimiento y el cliente debe inspeccionar los scopes concedidos en vez de suponer que todas las solicitudes tuvieron éxito. La prueba operativa es, por tanto, sencilla: rechaza todos los permisos que la tarea inmediata no necesite y demuestra después que el trabajo permitido sigue funcionando y que el trabajo denegado se detiene limpiamente hasta que el usuario vuelva a autorizarlo de forma deliberada.

Los scopes opcionales cambian la concesión, no la fiabilidad del cliente

El changelog del 22 de agosto de Cloudflare aplica los nuevos controles de consentimiento a Wrangler y al servidor MCP de la API de Cloudflare. La explicación más amplia del lanzamiento de OAuth añade dos detalles importantes para quienes implementan.

Primero, las etiquetas obligatorio y opcional se evalúan solo entre los scopes solicitados en ese flujo de autorización. Un cliente configurado para cuatro capacidades puede solicitar dos para una tarea limitada; solo esos dos aparecen y se clasifican para esa concesión. Segundo, la respuesta del token refleja la selección real del usuario. Un cliente que solicitó cuatro scopes pero recibió dos debe operar con dos, no tratar la diferencia como un error del servidor de autorización.

Esas páginas oficiales establecen el comportamiento anunciado, pero no ofrecen resultados independientes de compatibilidad para las combinaciones actuales de clientes de Wrangler o MCP. La matriz siguiente es, por tanto, una prueba de aceptación que se debe ejecutar, no una afirmación de que todos los clientes existentes ya gestionen correctamente una concesión parcial.

Hay tres decisiones separadas:

Decisión	Quién la controla	Qué se debe verificar
Qué scopes puede solicitar el cliente	El propietario del cliente al configurar el cliente OAuth	El conjunto configurado no contiene ninguna capacidad fuera del propósito documentado del producto
Qué scopes configurados son obligatorios	El propietario del cliente	Solo es obligatorio el conjunto mínimo de capacidades que el cliente necesita para arrancar y explicarse
Qué scopes opcionales solicitados entran en esta concesión	La persona que autoriza el flujo	La pantalla de consentimiento coincide con la tarea actual y la aplicación registra el conjunto de scopes devuelto sin registrar el token

La función mejora principalmente la tercera decisión y proporciona a los propietarios de clientes un mecanismo para la segunda. No puede rescatar a un cliente que etiqueta como obligatorio un acceso de escritura amplio. La guía de configuración de clientes de Cloudflare dice que todos los scopes seleccionados son obligatorios por defecto; el propietario debe marcar explícitamente una parte como opcional.

Wrangler expone un control relacionado pero distinto. Su documentación de comandos permite al operador solicitar un conjunto de scopes elegido al iniciar sesión, pero usa todos los scopes disponibles cuando no se proporcionan flags de scopes. Solicitar menos scopes limita lo que llega al consentimiento. Deseleccionar un scope opcional limita lo que concede el servidor de autorización. Una revisión de mínimo privilegio debe probar ambas rutas, no tratar la nueva pantalla de consentimiento como sustituto de una solicitud limitada.

Un scope rechazado pone a prueba al cliente tanto como al servidor de autorización

La diferencia entre los scopes solicitados y concedidos es esperable con un consentimiento parcial. La pregunta importante es si el cliente deriva sus herramientas disponibles de la concesión devuelta o supone que se aprobó cada permiso solicitado. Un cliente bien diseñado puede conservar su función básica, ocultar la acción no disponible y hacer visible cualquier aumento posterior de autoridad mediante una nueva autorización. Uno mal diseñado puede convertir la elección del usuario en un error genérico, un efecto secundario parcial o un intento silencioso de recuperar un acceso más amplio.

La visibilidad del cliente no resuelve la cuestión. Cloudflare dice que los clientes privados solo pueden ser autorizados por miembros de la cuenta principal. Los clientes públicos requieren verificar el dominio del editor, pero la guía de autorización de Cloudflare advierte que la verificación del dominio establece el control del dominio mostrado, no que la aplicación sea segura.

Cloudflare dice que un scope rechazado que después se vuelva necesario requiere una nueva autorización. Ese segundo evento de consentimiento es la función: permite al usuario ver que la tarea cambió y decidir si la capacidad adicional está justificada.

El consentimiento opcional no cierra el resto de la frontera de OAuth o de los agentes

Un token más pequeño limita lo que ese token puede autorizar. No demuestra que el flujo de autorización, el almacenamiento del token, el comportamiento del cliente o las herramientas posteriores sean seguros.

• El exceso de scopes obligatorios sigue siendo un exceso. El usuario no puede deseleccionar un scope obligatorio. Si el cliente puede ejecutar su función básica sin un permiso, clasifica ese permiso como opcional o no lo solicites.
• El valor predeterminado sigue siendo amplio. Cloudflare selecciona por defecto los permisos opcionales solicitados. Quien continúa sin editar recibe el conjunto completo solicitado, así que el cliente debe empezar por una solicitud limitada en vez de confiar en que cada usuario lo reduzca.
• La seguridad del flujo de autorización es independiente. Cloudflare documenta Authorization Code con PKCE para clientes públicos de navegador, móvil, escritorio y línea de comandos. Las buenas prácticas actuales de seguridad de OAuth del IETF también exigen PKCE para clientes públicos y la coincidencia exacta de las URI de redirección registradas. Los scopes opcionales no impiden la interceptación del código de autorización, los errores de redirección ni la falsificación de solicitudes entre sitios.
• El manejo de credenciales es independiente. El token bearer necesita la misma protección tanto con dos scopes como con veinte. La documentación actual de Wrangler ofrece almacenamiento en el llavero del sistema operativo; los registros, comentarios de incidencias, hojas de trabajo, prompts y contexto del modelo deben contener nombres de scopes y evidencia no secreta, nunca tokens ni credenciales de actualización.
• Una concesión segura puede dirigir una herramienta insegura. Los scopes opcionales no validan los argumentos de las herramientas MCP, no vinculan una acción con la intención actual del usuario, no impiden un flujo de confused deputy ni añaden aprobación antes de una llamada destructiva. Siguen siendo necesarias la validación a nivel de herramienta, las fronteras de cuenta y recurso, la confirmación humana y los controles de recuperación.
• Los nombres de los scopes no miden por sí solos las consecuencias. Un único scope de escritura puede ser más peligroso que diez scopes de lectura. Revisa el recurso, la cuenta, la operación, la sensibilidad de los datos, la reversibilidad y los efectos posteriores que hay detrás de cada nombre.

Es la misma distinción que subyace al análisis del roadmap de MCP (en español): la documentación establece un mecanismo disponible, mientras que el par de cliente y servidor desplegado determina el comportamiento real. El análisis de Claude Skills API (en español) aplica la misma regla a los paquetes de agentes reutilizables.

El cambio de Cloudflare convierte el consentimiento OAuth parcial en un control utilizable para los clientes de Wrangler y MCP. La prueba no es el nuevo botón «Editar permisos». Es la ejecución en la que una capacidad rechazada sigue rechazada, el trabajo útil continúa y la autoridad añadida no puede aparecer sin otra concesión deliberada.

Fuentes

1. Cloudflare changelog: Choose OAuth scopes for Wrangler and the Cloudflare API MCP server
2. Cloudflare: From all-or-nothing to task-based OAuth consent
3. Cloudflare OAuth client configuration documentation
4. Cloudflare application authorization documentation
5. Cloudflare Wrangler general commands documentation
6. IETF RFC 9700: Best Current Practice for OAuth 2.0 Security