Cloudflare anunció la incorporación de la personalización de ámbitos de OAuth, una función que permite a los propietarios de aplicaciones OAuth de terceros definir permisos obligatorios y opcionales. De este modo, durante la pantalla de consentimiento, el usuario puede cancelar los permisos opcionales y conceder a la aplicación un nivel de acceso más limitado, en lugar de tener que elegir entre aceptar todos los permisos solicitados o rechazar la solicitud por completo.
La medida llega después de que los desarrolladores crearan miles de aplicaciones OAuth de terceros en Cloudflare desde junio, con más de un millón de operaciones de autorización registradas desde entonces. Estas aplicaciones se utilizan en integraciones de software como servicio, herramientas internas, interfaces de línea de comandos y agentes de software.
Del consentimiento general a los permisos vinculados a la tarea
Cloudflare OAuth permitía que la aplicación solicitara un subconjunto de los ámbitos configurados para ella, pero el usuario no podía reducir ese conjunto desde la propia pantalla de consentimiento. Si la aplicación solicitaba más permisos de los que el usuario consideraba adecuados, este solo podía conceder la solicitud completa o rechazarla.
Cloudflare explica que los servidores MCP representan un caso de uso claro de este problema; un servidor MCP puede solicitar un conjunto amplio de permisos porque el agente podría necesitar, en teoría, todos ellos, mientras que el usuario no necesariamente desea concederle ese nivel de acceso. Antes del lanzamiento de la función, el desarrollador tenía que crear una pantalla personalizada para seleccionar los ámbitos antes de redirigir al usuario al flujo de consentimiento de Cloudflare.
¿Cómo funcionan los ámbitos opcionales?
- El desarrollador puede definir determinados ámbitos como obligatorios u opcionales al configurar un cliente OAuth.
- El usuario puede desmarcar los ámbitos opcionales dentro del conjunto de permisos solicitados en el proceso de autorización actual.
- La experiencia predeterminada permanece sin cambios si el cliente no activa los ámbitos opcionales, y la pantalla de consentimiento también concede el conjunto completo solicitado cuando no se cancela ningún ámbito opcional.
El punto importante es que la evaluación se realiza según los ámbitos que la aplicación solicitó en un flujo de autorización específico, y no según todos los ámbitos configurados en el cliente. Si el cliente incluye user-details.read, workers-scripts.write, workers-kv-storage.write y zone.read, y los dos últimos se establecen como opcionales, la solicitud de los cuatro ámbitos permite al usuario cancelar únicamente los dos últimos.
Sin embargo, si el cliente solicita posteriormente solo workers-scripts.write y zone.read, únicamente esos dos ámbitos se evaluarán en esa operación. Los demás ámbitos no aparecerán ni se impondrán, porque no formaban parte de la solicitud actual. Esto ayuda a mantener la pantalla de consentimiento centrada en la tarea solicitada, en lugar de mostrar todas las capacidades que la aplicación podría solicitar en el futuro.
¿Qué cambia en la práctica para los desarrolladores?
Cuando el usuario cancela algunos ámbitos opcionales y completa la autorización, el token de acceso resultante contendrá únicamente los permisos que haya aprobado. Por ello, el desarrollador debe comprobar el conjunto de ámbitos concedidos después de intercambiar el código de autorización, en lugar de asumir que la aplicación obtuvo el conjunto completo solicitado.
Esto significa que las aplicaciones, especialmente los agentes de software, deben gestionar correctamente la concesión parcial de permisos. Además, solicitar el nivel mínimo de acceso necesario y hacer opcionales los permisos adicionales deja claro al usuario que la aplicación respeta su decisión sobre los límites de acceso.
Ampliación a los productos de Cloudflare
Cloudflare afirmó que durante las semanas siguientes ampliará los ámbitos de roles a nivel de cuenta y zona para cubrir prácticamente todos sus productos, incluidos más roles de tokens de API, opciones de pertenencia a cuentas y ámbitos de OAuth. Los desarrolladores pueden comenzar a través de la documentación de Third Party OAuth o desde la página de aplicaciones OAuth del panel de control.
La empresa indicó que la función se desarrolló con la ayuda de 1.111 becarios, y elogió las contribuciones de Miller Vargas y José Enrique Rodriguez. Según el artículo, Vargas estudia Ciencias de la Computación y Matemáticas en University of Texas - Austin, mientras que Rodriguez estudia Ingeniería, Inteligencia de Datos y Ciberseguridad en Universidad Panamericana.