Permisos delegados frente a permisos de aplicación: cómo elegir el modelo adecuado para tu aplicación

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Bienvenido de nuevo al podcast y a nuestra serie continua para ayudarte a dominar Microsoft 365, Azure y las herramientas para desarrolladores que impulsan el ecosistema cloud actual. Si alguna vez has creado una integración, escrito un script o desplegado automatizaciones empresariales con la API de Microsoft Graph, seguro que te has topado con el muro de los permisos. Proteger tu inquilino mientras construyes aplicaciones funcionales es uno de los equilibrios más críticos a los que te enfrentarás como administrador o desarrollador. Elegir entre distintos modelos de permisos afecta directamente a tu postura de seguridad, a la velocidad de despliegue y a la arquitectura general del sistema.

Para profundizar en este tema, hace poco grabamos un episodio en detalle. No te pierdas la discusión completa en audio en Microsoft Graph Permissions and Consent Models Explained. En este artículo complementario ampliaremos esos conceptos: analizaremos las diferencias fundamentales entre permisos delegados y de aplicación, revisaremos los modelos de consentimiento, veremos buenas prácticas y ofreceremos un marco completo para que tus aplicaciones sigan siendo seguras y cumplan la normativa.

Descripción general de los permisos de la API de Microsoft Graph

Antes de entrar en los matices de los flujos de autorización concretos, conviene entender qué son realmente los permisos de la API de Microsoft Graph. En esencia, Microsoft Graph actúa como una puerta de enlace unificada a los datos almacenados en los servicios de Microsoft 365, como Exchange Online, SharePoint, Microsoft Teams, OneDrive y Azure Active Directory (Microsoft Entra ID). En lugar de obligar a los desarrolladores a autenticarse contra múltiples endpoints aislados, Microsoft Graph ofrece un único endpoint de API REST. Sin embargo, como esta API da acceso a prácticamente todos los rincones del patrimonio digital de una organización, protegerla requiere un marco de permisos robusto y granular.

Permisos delegados frente a permisos de aplicación

Cuando registras una aplicación en la plataforma de identidad de Microsoft, debes declarar explícitamente cómo va a interactuar tu aplicación con los recursos. Básicamente, esto se reduce a elegir entre dos tipos principales de permisos: permisos delegados y permisos de aplicación. Estas decisiones determinan cómo se autentica tu aplicación, a quién o a qué representa y los límites de los datos que puede recuperar.

Los permisos delegados están pensados para aplicaciones de cliente o de cara al usuario, como aplicaciones web de una sola página, aplicaciones móviles o utilidades de escritorio, en las que hay un usuario que ha iniciado sesión y está presente. En este modelo, tu aplicación actúa *en nombre de* el usuario. La aplicación solo puede acceder a los datos y realizar las acciones para las que el propio usuario tiene derechos. Cuando un usuario abre la aplicación, se le pide que inicie sesión y conceda su consentimiento de forma explícita, lo que genera un token de acceso de OAuth 2.0 que contiene tanto la identidad del usuario como los ámbitos consentidos.

Los permisos de aplicación, en cambio, los utilizan servicios en segundo plano, daemons, web jobs y runbooks automatizados que funcionan con independencia de cualquier contexto de usuario. Aquí, la aplicación se ejecuta con su propia identidad. Utiliza credenciales de cliente, como un secreto de cliente, un par de claves de certificado público/privado o una identidad administrada, para obtener de Azure AD un token de acceso solo de aplicación. Como ningún usuario humano está delante del teclado para autenticarse, estos permisos abarcan recursos de todo el inquilino. Por ello, conllevan riesgos de seguridad considerablemente mayores y siempre requieren el consentimiento explícito de un administrador del inquilino.

Diferencias clave y casos de uso

Entender cuándo aplicar cada modelo de permisos evita cuellos de botella en la arquitectura y vulnerabilidades de seguridad. Veamos un breve desglose comparativo:

Permisos delegados: la aplicación trabaja para un usuario. El usuario debe iniciar sesión y dar su consentimiento. La aplicación solo puede ver lo que el usuario puede ver. Este modelo es ideal para aplicaciones cliente que leen o escriben datos personales, como calendarios o correos individuales.
Permisos de aplicación: la aplicación trabaja como sí misma. No es necesario que ningún usuario inicie sesión. Un administrador debe dar su consentimiento. La aplicación puede ver y modificar datos de todo el inquilino. Este modelo es ideal para la sincronización en segundo plano, los informes administrativos y los trabajos automatizados de gobernanza.

Elegir el modelo correcto depende por completo de la arquitectura de tu aplicación. Por ejemplo, si estás creando un panel interactivo que muestra el perfil de un usuario y su bandeja de entrada personal, debes usar permisos delegados. En cambio, si desarrollas un script automatizado que analiza todos los buzones de la organización a medianoche para auditorías de cumplimiento, necesitas permisos de aplicación.

Permisos delegados en Microsoft Graph

Cómo funcionan los permisos delegados

El acceso delegado está muy ligado a la identidad del usuario. Cuando tu aplicación solicita un permiso delegado, en esencia está pidiendo al servidor de autorización permiso para suplantar al usuario que ha iniciado sesión, dentro de límites definidos. El token de acceso devuelto mediante el flujo de código de autorización de OAuth contiene notificaciones de ámbito específicas que reflejan tanto los derechos propios del usuario como los permisos solicitados por la aplicación.

El acceso delegado significa que tu aplicación actúa directamente como el usuario.
Tanto el registro de la aplicación como el usuario individual deben tener los derechos subyacentes adecuados.
Los ámbitos definen el límite exacto de lo que tu aplicación puede hacer en nombre del usuario.
El token de acceso resultante vincula conjuntamente la identidad de la aplicación y el contexto del usuario.

Escenarios habituales para permisos delegados

Los permisos delegados impulsan la mayoría de las integraciones de productividad del día a día. Por ejemplo, si una aplicación empresarial de notas necesita sincronizar archivos con la cuenta OneDrive de un usuario, solicita el ámbito Files.ReadWrite. Si el usuario no tiene permiso para acceder a un documento concreto, la API de Graph rechazará la solicitud, aunque el ámbito de la aplicación lo permita técnicamente. De forma similar, las aplicaciones que usan el SDK de Microsoft Graph para enviar notificaciones automáticas por correo en nombre de un usuario aprovechan ámbitos delegados como Mail.Send.

Consideraciones de seguridad y consentimiento

Aunque los permisos delegados son, por naturaleza, más seguros que los permisos de aplicación a nivel de inquilino, porque están limitados por las restricciones del usuario, siguen presentando desafíos de seguridad particulares. Si una aplicación solicita ámbitos demasiado amplios, como acceso completo al buzón y al perfil de directorio de un usuario, un ataque de phishing exitoso o el compromiso de la aplicación podría exponer datos personales sensibles. Los desarrolladores deben aplicar estrictamente el principio de mínimo privilegio, solicitando únicamente los ámbitos específicos necesarios para la funcionalidad inmediata.

Permisos de aplicación en Microsoft Graph

Cómo funcionan los permisos de aplicación

Los permisos de aplicación eliminan el elemento humano de la ecuación de autenticación. En lugar de interactuar con una solicitud de inicio de sesión, la aplicación se autentica directamente con Microsoft Entra ID mediante credenciales de cliente. El token resultante contiene roles de aplicación en lugar de ámbitos delegados, lo que concede a la entidad de servicio un acceso amplio y sin restricciones a los recursos de todo el inquilino.

Los permisos de aplicación funcionan por completo sin un usuario que haya iniciado sesión.
La aplicación obtiene un token exclusivo de aplicación para consultar recursos.
El acceso se rige por los roles de aplicación asignados a la entidad de servicio, no por los privilegios de un usuario individual.

Cuándo usar permisos de aplicación

Debes restringir los permisos de aplicación estrictamente a cargas de trabajo de backend, demonios sin supervisión e integraciones entre sistemas. Algunos ejemplos son los motores de aprovisionamiento automático de usuarios, los sistemas centralizados de copia de seguridad, las herramientas de respuesta a incidentes de seguridad y los scripts de migración de inquilinos.

Consentimiento de administrador e implicaciones de seguridad

Como los permisos de aplicación eluden las restricciones de cada usuario y conceden acceso a nivel de inquilino, los usuarios normales no pueden consentirlos. Solo un administrador con privilegios puede conceder el consentimiento de aplicación. Una configuración incorrecta de los permisos de aplicación, como conceder Directory.ReadWrite.All o Mail.ReadWrite.All a una aplicación en segundo plano no confiable o mal programada, puede dejar todo un inquilino de Microsoft 365 expuesto a un compromiso total. Audita con regularidad las entidades de servicio de tus aplicaciones empresariales.

Pros y contras de los permisos de la API de Microsoft Graph

Pros

Modelo de permisos unificado: Un marco de autorización único y coherente en todos los servicios de Microsoft 365 simplifica la administración.
Ámbitos granulares: Los ámbitos delegados y de aplicación detallados permiten arquitecturas de mínimo privilegio precisas.
OAuth2/OpenID Connect estándar: Aprovecha protocolos de seguridad del sector para una integración de identidad sencilla.
Integración con RBAC: Se conecta sin fricciones con los roles de Azure AD y las directivas de Conditional Access para lograr un cumplimiento centralizado.
Consentimiento incremental: Permite que las aplicaciones soliciten permisos adicionales con el tiempo, en lugar de exigir todos desde el principio.

Desventajas

Complejidad: Entender la intersección entre los permisos delegados, los roles de aplicación y los modelos de consentimiento de administrador puede abrumar a quienes empiezan.
Riesgos por privilegios elevados: Configurar mal permisos amplios (como Sites.FullControl.All) puede exponer grandes cantidades de datos corporativos.
Cuellos de botella en el consentimiento de administrador: Exigir la aprobación administrativa para permisos de alto impacto puede ralentizar los ciclos de desarrollo ágiles.
Documentación fragmentada: Los desarrolladores suelen tener que consultar varios repositorios de documentación de Microsoft para averiguar el comportamiento exacto de las API.

Modelos de consentimiento y buenas prácticas

Consentimiento de usuario frente a consentimiento de administrador en Microsoft Graph

Gestionar cómo se obtiene el consentimiento es clave para la gobernanza de la organización. El consentimiento de usuario permite a cada persona autorizar a las aplicaciones a acceder a sus datos personales. El consentimiento de administrador traslada el punto de aprobación a los administradores de TI, que evalúan las solicitudes de las aplicaciones en nombre de toda la organización. Las líneas base de seguridad empresariales modernas suelen deshabilitar por completo el consentimiento de usuario, de modo que toda incorporación de aplicaciones pasa por flujos formales de aprobación previa por parte del administrador.

Impacto de las directivas del inquilino en los permisos

Las directivas del inquilino empresarial pueden alterar de forma fundamental el comportamiento de tu aplicación en tiempo de ejecución. Si un administrador ha aplicado directivas estrictas de Conditional Access, como exigir autenticación multifactor (MFA) o dispositivos unidos a Azure AD híbrido y conformes, una aplicación que intente obtener un token de Graph sin cumplir esos criterios será bloqueada. Los desarrolladores deben diseñar sus aplicaciones para gestionar los errores de obtención de tokens con elegancia y ofrecer pasos claros de corrección.

Estrategias para un flujo de consentimiento fluido

Para evitar fricciones con los usuarios y bloqueos administrativos, planifica tu estrategia de permisos antes de escribir código. Implementa patrones de consentimiento incremental: tu aplicación solicita al principio los permisos básicos de identidad y pide permisos de recursos específicos solo cuando el usuario accede a esas funciones concretas. Utiliza flujos automatizados de aprobación previa en Microsoft Entra ID para agilizar el desarrollo sin renunciar a un control de seguridad estricto.

Errores comunes con los permisos de la API de Microsoft Graph

Confundir los permisos delegados y de aplicación, y no entender los requisitos del contexto de usuario.
Solicitar demasiados permisos desde el principio en lugar de adoptar un enfoque de mínimo privilegio.
No tener en cuenta los requisitos de consentimiento de administrador al desplegar servicios en segundo plano.
Suponer que los cambios de permisos en Azure portal surten efecto de inmediato sin renovar el token.
Presentar un token de acceso delegado cuando se requiere un token de credenciales de cliente.
Ignorar las directivas de Conditional Access que bloquean las solicitudes a la API de Graph en tiempo de ejecución.
Olvidar validar las notificaciones de ámbito (scope claims) en el código de la aplicación durante la ejecución.
No auditar con el tiempo los permisos de aplicación concedidos y las entidades de servicio.

Lista de comprobación de permisos de la API de Microsoft Graph

Usa esta lista de comprobación práctica para guiar a tu equipo en el diseño, la implementación y la auditoría de los permisos de la API de Microsoft Graph de forma segura:

Conclusión

Orientarse en los permisos de la API de Microsoft Graph no tiene por qué ser una fuente de frustración. Si entiendes con claridad las diferencias operativas entre los permisos delegados (que requieren un usuario que haya iniciado sesión y funcionan dentro de los límites de ese usuario) y los permisos de aplicación (que se ejecutan en segundo plano sin esas restricciones y requieren consentimiento de administrador), podrás diseñar soluciones seguras y escalables. Aplicar el principio de mínimo privilegio, auditar con rigor y aprovechar las herramientas de gobernanza empresarial mantendrá tu entorno de Microsoft 365 seguro sin frenar la innovación.

Para más orientación experta, estrategias reales y análisis en profundidad sobre la seguridad de tu entorno en la nube, no dejes de escuchar nuestro desglose completo en audio del episodio relacionado: Microsoft Graph Permissions and Consent Models Explained. Mantén tus permisos bien ajustados, tus credenciales seguras, ¡y feliz programación!