Permisos delegados frente a permisos de aplicación

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Compara los permisos delegados y los permisos de aplicación en Microsoft Entra ID y elige el modelo de acceso adecuado para API seguras, la automatización y el desarrollo de aplicaciones.

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

Cuando trabajas con Microsoft Entra ID, saber quién puede hacer qué y en qué circunstancias es mucho más que un detalle técnico. Es la base del desarrollo seguro de aplicaciones, la automatización y la gestión de identidades en la nube de Microsoft. Hay una gran diferencia entre permitir que los usuarios concedan a tu aplicación solo el acceso necesario para actuar en su nombre (permisos delegados) y dar a una aplicación las llaves para actuar por sí misma (permisos de aplicación).

Si lo haces mal, puedes abrir la puerta a exposición no deseada de datos, problemas de cumplimiento normativo o incluso incidentes de seguridad. Si lo haces bien, consigues automatizaciones más fluidas, una gobernanza más clara y auditores más satisfechos. Esta guía te ofrece el panorama completo: los fundamentos de estos tipos de permisos, cómo se aplican en la práctica y todos los aspectos de seguridad, gobernanza y operaciones que necesitas para tomar la mejor decisión en tu entorno. Pongamos los permisos en su lugar, porque un gran acceso conlleva una gran responsabilidad.

Introducción y contexto de los modelos de permisos en Microsoft Identity

Los permisos en Microsoft Entra ID no son simples casillas que marcas; son un marco fundamental integrado en la forma en que las aplicaciones y los usuarios interactúan en Microsoft 365, Azure y más allá. Cuando Microsoft trasladó la identidad a la nube, necesitaba una forma de que los servicios y las herramientas de terceros interactuaran de manera segura, sin conceder acceso total a todo el mundo. Así surgieron los permisos delegados y los permisos de aplicación.

Estos modelos permiten gestionar con precisión quién puede acceder a qué, y establecen límites claros entre lo que un usuario individual puede aprobar y lo que solo debe autorizar un administrador. Son el resultado de años de aprendizaje (a veces por las malas) con las cuentas de servicio clásicas de AD y con accesos rígidos de todo o nada. Entender estos modelos no es solo una buena práctica: es fundamental para cumplir la normativa, aplicar Zero Trust y evitar que las operaciones del día a día se detengan por configuraciones de seguridad incorrectas.

Permisos de aplicación frente a permisos delegados: conceptos básicos y escenarios reales

Vamos a explicar la diferencia entre permisos delegados y permisos de aplicación en términos sencillos. Piensa en los permisos delegados como una aplicación que actúa como ayudante: solo obtiene acceso mientras un usuario concreto tiene la sesión iniciada, y se limita a lo que ese usuario podría hacer. Los permisos de aplicación, en cambio, permiten que tu aplicación actúe de forma independiente, como un gerente sin supervisión con su propio juego de llaves. No necesita que haya ningún usuario presente.

Con los permisos delegados, la autenticación siempre implica a un usuario. Eso significa que, cuando alguien inicia sesión, por ejemplo en una aplicación que necesita acceder a su correo o a su calendario, le concede a la aplicación una ventana temporal para operar con su autoridad. Si el usuario cierra la sesión, esa ventana se cierra. Esto es ideal para aplicaciones que trabajan a petición del usuario, como interfaces web, bots de Teams o aplicaciones móviles de productividad.

Con los permisos de aplicación, la propia aplicación se autentica con su propia identidad (una entidad de servicio, o service principal) y obtiene su propio token. Esto es lo que impulsa la automatización y los trabajos en segundo plano, como una integración de sistemas que sincroniza datos entre SharePoint y tu CRM durante la noche. No requiere interacción del usuario: la aplicación realiza las tareas según su propia programación y con su propio nivel de acceso, siempre sujeto a lo que apruebe un administrador.

Imagina que necesitas automatizar el aprovisionamiento de usuarios: un servicio en segundo plano que actualiza las cuentas de usuario cada noche. Aquí los permisos delegados no sirven de nada, ya que no hay nadie disponible para aprobar el acceso. Pero cuando tu solución necesita ofrecer funciones personalizadas mientras el usuario está activo, como una aplicación de firma de documentos vinculada a OneDrive, ahí es donde brillan los permisos delegados.

Los escenarios reales suelen requerir una combinación de ambos modelos, así que saber qué modelo encaja con tu caso de uso es fundamental para la experiencia de usuario, la gobernanza y la seguridad. No quieres entregar más llaves de las necesarias, pero tampoco quieres que tu servicio se quede bloqueado a las 3 de la madrugada porque no hay nadie para iniciar sesión.

Funcionamiento interno de los permisos delegados de Microsoft Entra: flujo de autenticación y limitaciones

Los permisos delegados en Microsoft Entra ID siguen un flujo de autenticación clásico iniciado por el usuario. Comienza cuando un usuario inicia sesión en tu aplicación con sus credenciales de Microsoft. En ese momento, la aplicación solicita permisos específicos (o ámbitos), mostrando al usuario (y a veces a un administrador) exactamente qué tipo de datos o acciones quiere utilizar.

Si los permisos solicitados solo requieren consentimiento del usuario, este los aprueba en el momento a través de una pantalla de consentimiento. En el caso de permisos más sensibles (como leer el buzón de todos los usuarios de la organización), se requiere consentimiento de administrador. Una vez otorgado el consentimiento, tu aplicación recibe un token de acceso vinculado directamente a la identidad del usuario y a los roles que tiene asignados.

Ese token de acceso es lo que permite a la aplicación llamar a Microsoft Graph o a las API de Microsoft 365, pero siempre actúa con la autoridad del usuario. Por tanto, si el usuario es un empleado estándar, la aplicación no puede saltar de repente a funciones de administrador. En cuanto el usuario cierra sesión, el acceso de la aplicación se agota, lo que mantiene reducido el radio de impacto.

Pero aquí está la limitación: los permisos delegados fallan en escenarios desatendidos. Si ejecutas un proceso en segundo plano, una tarea programada o una integración de servicios que no debería depender de que alguien inicie sesión activamente, los permisos delegados simplemente no sirven. Todo depende de la presencia del usuario, así que el soporte, la automatización y los trabajos nocturnos chocan contra un muro.

También hay que considerar el aspecto de seguridad. Si un usuario con amplio acceso es engañado para dar su consentimiento, una aplicación podría abusar de esos permisos, un vector clave en los ataques de phishing por consentimiento. Por eso necesitas controles estrictos sobre quién puede conceder qué permisos y una formación sólida que conciencie sobre lo que realmente significan esas pantallas de consentimiento.

Exceso de permisos en el acceso de aplicaciones y seguridad de los tokens en Microsoft Entra ID

En lo que respecta a los permisos, más no siempre es mejor. De hecho, el exceso de permisos (conceder privilegios innecesarios o excesivos, sobre todo con permisos de aplicación) puede abrir la puerta a fugas de datos sensibles e incidentes de seguridad graves. Imagina que das a una aplicación acceso de lectura y escritura a todos los buzones de la empresa, pero solo necesita leer eventos del calendario: acabas de ampliar considerablemente tu superficie de ataque.

Este peligro no es solo teórico. Los atacantes están explotando el abuso del consentimiento de OAuth para saltarse incluso la autenticación multifactor. Se dirigen a usuarios o administradores con avisos de consentimiento muy bien elaborados, engañándolos para que aprueben permisos de riesgo. Una vez dentro, esas aplicaciones maliciosas suelen conservar el acceso incluso si se cambian las contraseñas o se exige MFA. El control del atacante persiste, y las defensas tradicionales dejan de ser eficaces. Para un análisis de un caso real, consulta esta explicación sobre cómo los atacantes abusan del consentimiento de OAuth en Entra ID y las mejores formas de protegerlo.

La conversación no se limita al exceso de permisos. Los tokens y las credenciales, incluidos los secretos de cliente y los certificados, pueden convertirse en un gran botín para los atacantes si no están protegidos. Un secreto de cliente filtrado de un registro de aplicación solo de aplicación es todo lo que necesita un atacante para suplantar tu servicio. Por eso la higiene de credenciales es esencial: usa identidades administradas siempre que sea posible, rota los secretos y nunca almacenes credenciales de cliente en el código ni en archivos sin protección. En entornos que dependen de accesos no humanos, considera las identidades de carga de trabajo de Microsoft Entra, que permiten un acceso sin secretos y auditable, y eliminan los dolores de cabeza de las cuentas de servicio heredadas. Aquí tienes un análisis más profundo sobre por qué las identidades de carga de trabajo son imprescindibles para Zero Trust.

Por último, la supervisión adecuada no es negociable. Revisa con regularidad los registros de inicio de sesión y las concesiones de OAuth, configura alertas para consentimientos o usos de tokens sospechosos, y adelántate al phishing por consentimiento y al robo de tokens. Los hallazgos de incidentes reales (como esta cadena de ataque de Microsoft 365) demuestran que los atacantes aprovechan una gobernanza débil, así que cuanta más visibilidad, mejor. Protege las claves, ajusta los permisos y mantén tus aplicaciones bajo control.

Controles y buenas prácticas para gestionar permisos delegados y de aplicación

• Implementa los controles integrados de Entra para la gestión de permisosAprovecha los flujos de consentimiento integrados, los procesos de aprobación del administrador y las directivas detalladas de Microsoft Entra para restringir qué usuarios o grupos pueden conceder permisos. Usa directivas de consentimiento de administrador para garantizar que solo las aplicaciones revisadas reciban ámbitos de alto riesgo.
• Aplica el principio de mínimo privilegioConcede a las aplicaciones únicamente el conjunto mínimo de permisos necesario para su función. Revisa cada permiso que se solicite durante el registro de la aplicación y elimina todo lo que no sea necesario. El mínimo privilegio es tu mejor defensa frente al uso indebido y a los excesos de acceso.
• Programa revisiones periódicas de permisos y auditoríasConfigura revisiones de acceso rutinarias, utilizando los paneles de permisos y consentimiento de Entra, para identificar y revocar permisos que no se usan o que representan un riesgo. Automatiza estas comprobaciones cuando sea posible para lograr una gobernanza escalable, tal como se describe en guías de gobernanza avanzada como esta estrategia de Microsoft Purview.
• Supervisa los cambios de permisos y configura alertasEstablece monitorización y alertas para detectar nuevas concesiones OAuth, picos en el uso de permisos de aplicaciones o integraciones inesperadas de administrador. La notificación proactiva te da tiempo para responder antes de que los problemas de seguridad se agraven.
• Protege el almacenamiento de tokens y credencialesGuarda los secretos de cliente y los tokens en almacenes seguros como Azure Key Vault. Rota las credenciales con regularidad, usa certificados en lugar de secretos compartidos y prefiere las identidades de carga de trabajo para los accesos no humanos, ya que ofrecen una mejor gestión del ciclo de vida y mayor capacidad de auditoría.
• Adopta la gobernanza avanzada y la automatización de directivasAprovecha herramientas como Microsoft Purview y Azure Policy para aplicar controles en todo el inquilino, segmentar el riesgo con Data Loss Prevention y diseñar para un cumplimiento continuo. Para ver un enfoque práctico de la gobernanza por diseño mediante directivas, consulta la estrategia de gobernanza empresarial de Azure.

Si sigues estos pasos y utilizas el ecosistema de herramientas de gobernanza de Microsoft, podrás gestionar los riesgos de permisos antes de que se conviertan en problemas. Enseña a los usuarios de forma periódica las buenas prácticas de consentimiento, automatiza siempre que puedas y recuerda que la gestión de permisos nunca es una tarea puntual. Mantente alerta, sigue refinando las directivas y tu entorno de Entra ID se mantendrá en buen estado.

También te recomendamos estos episodios

Si estás explorando permisos delegados frente a permisos de aplicación en Entra ID, estos episodios aportan contexto práctico para una adopción segura de Microsoft 365, la protección de datos, la gobernanza y la gestión de riesgos de la IA.

• Microsoft Purview – Simply Explained — Descubre cómo la clasificación, la retención, el cumplimiento y la protección encajan en un único modelo de gobernanza de datos de Microsoft.
• Microsoft Defender XDR – Simply Explained — Conecta los controles de protección de datos con la detección, la investigación y la respuesta.
• Conditional Access – Simply Explained — Comprende cómo las señales de identidad y riesgo aportan contexto a las decisiones de acceso.
• Microsoft AI Agent Harness – Simply Explained — Explora los controles que hacen que la automatización con IA sea más fiable, observable y segura.

Estos episodios te ayudarán a convertir los conceptos del artículo en decisiones prácticas de diseño e implementación.