Permisos delegados frente a permisos de aplicación en Microsoft Entra ID: lo que los administradores necesitan saber

By Mirko Peters · 2026-10-28

Conoce las diferencias críticas entre los permisos delegados y los permisos de aplicación en Microsoft Entra ID, incluidas las mejores prácticas de seguridad y las reglas de mínimo privilegio.

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

Al integrar herramientas de terceros o aplicaciones personalizadas en tu entorno de Microsoft 365, entender la diferencia entre permisos delegados y permisos de aplicación es fundamental para mantener la seguridad en la nube, prevenir fugas de datos y aplicar el principio de mínimo privilegio en Microsoft Entra ID.

Puntos clave

• Los permisos delegados requieren un usuario que haya iniciado sesión y actúan en su nombre, lo que significa que la aplicación solo puede acceder a los datos que el usuario tiene derecho a ver.
• Los permisos de aplicación funcionan sin un usuario humano, conceden un acceso amplio a todo el inquilino y requieren la aprobación de un administrador.
• El principio de mínimo privilegio dicta que las aplicaciones siempre deben recibir el conjunto más pequeño de permisos necesario para completar su tarea.
• Microsoft Graph actúa como la puerta unificada de acceso a los datos de Microsoft 365, y depende en gran medida de estos modelos de permisos.
• Entender la diferencia evita graves brechas de seguridad, como conceder accesos no previstos a todo el inquilino a aplicaciones de terceros.

Comprender los permisos de OAuth en la nube de Microsoft

Cuando conectas una herramienta de productividad externa o un script de automatización interno a tu espacio de trabajo de Microsoft 365, activas un flujo subyacente de OAuth 2.0. Sin embargo, obtener un token de acceso es solo la mitad del trabajo. El verdadero límite de seguridad lo define lo que ese token puede hacer realmente. En el ecosistema de identidad de Microsoft, centrado en Microsoft Entra ID (antes Azure Active Directory), los permisos se dividen en dos tipos fundamentalmente distintos: permisos delegados y permisos de aplicación.

Confundir estos dos modelos es uno de los errores más comunes para administradores de TI, desarrolladores y usuarios avanzados por igual. Elegir el tipo de permiso incorrecto puede exponer accidentalmente datos de toda la empresa o romper por completo la funcionalidad de una aplicación. Veamos cómo funciona cada tipo, dónde se gestionan y cómo gobernarlos correctamente.

Permisos delegados: actuar en nombre de un usuario

Los permisos delegados están diseñados para aplicaciones que tienen a una persona delante. Cuando inicias sesión en una aplicación móvil o un servicio web con tu cuenta de Microsoft, la aplicación toma prestada tu identidad para un conjunto específico de tareas. Esto se conoce como permiso delegado.

En este escenario, la aplicación actúa como tú. Solo puede acceder a los datos a los que ya tienes permiso, y nada más. Si tu cuenta de usuario no tiene acceso de lectura a una carpeta concreta de SharePoint o al calendario de un compañero, la aplicación tampoco podrá acceder a ellos. Como el alcance del posible daño está naturalmente limitado por los permisos del usuario individual, Microsoft recomienda usar permisos delegados siempre que haya una persona implicada en el flujo de trabajo.

Cómo aparecen los permisos delegados en la práctica

Interactúas con los permisos delegados cada vez que haces clic en un mensaje de consentimiento. Un asistente de programación puede mostrar una pantalla que indica que quiere leer tu calendario. Esa solicitud representa un ámbito específico de OAuth. Como estás presente para aprobar o rechazar la solicitud, actúas como propietario del recurso y controlas con precisión qué puede tomar prestado la aplicación cliente de tu perfil.

Permisos de aplicación: servicios en segundo plano y acceso a todo el inquilino

Los permisos de aplicación funcionan con un paradigma completamente distinto. Están diseñados para daemons en segundo plano, scripts de sincronización automatizados y servicios de backend que se ejecutan a las tres de la madrugada, cuando ningún usuario ha iniciado sesión. Piensa en una herramienta automatizada de generación de informes que agrega datos de todos los buzones de la organización.

Como no hay ningún usuario presente que aporte el contexto de identidad, la aplicación se autentica con sus propias credenciales (como un identificador de cliente y un secreto de cliente mediante el flujo de credenciales de cliente). Por consiguiente, los permisos de aplicación otorgan a la herramienta la capacidad de actuar en nombre propio en toda la organización. Si una aplicación tiene permisos de aplicación para leer correo, puede leer el correo de cada uno de los usuarios del inquilino.

Por qué el consentimiento de administrador es obligatorio

Dado el enorme poder que conllevan los permisos de aplicación, los usuarios normales no pueden darles su consentimiento. Mientras que un empleado estándar puede aprobar un permiso delegado para su propio calendario, los permisos de aplicación requieren la aprobación explícita de un administrador global o de un administrador de roles privilegiados. Este control estricto impide que aplicaciones maliciosas o mal programadas recopilen discretamente datos de toda la organización.

Microsoft Graph y el papel de los ámbitos de OAuth

Tanto si una aplicación usa permisos delegados como permisos de aplicación, en última instancia dirige sus solicitudes a una única y potente puerta de enlace: Microsoft Graph. Cada chat de equipo, documento de SharePoint, archivo de OneDrive y correo de Outlook es accesible a través de Microsoft Graph, siempre que la aplicación que realiza la llamada presente un token de acceso de OAuth válido.

Las barreras que mantienen honestos a estos tokens se llaman ámbitos. Un ámbito es una etiqueta precisa incrustada en el token que define límites exactos, como leer un calendario frente a enviar un correo. Cuando los desarrolladores solicitan ámbitos excesivamente amplios (por ejemplo, pedir acceso de lectura y escritura cuando bastaría con acceso de solo lectura), vulneran las mejores prácticas de seguridad fundamentales. Los administradores deben auditar estos ámbitos con detenimiento durante las revisiones del registro de aplicaciones.

Aplicar el principio de mínimo privilegio en tu inquilino

Las mejores prácticas de seguridad en Microsoft Entra ID siempre regresan a una regla de oro: el principio de mínimo privilegio. Cada aplicación, entidad de servicio y script de automatización debe tener concedido el nivel de acceso absolutamente mínimo necesario para completar su tarea.

• Prefiere siempre los permisos delegados a los permisos de aplicación cuando un usuario humano interactúa con la aplicación.
• Revisa con atención las solicitudes de consentimiento para asegurarte de que las aplicaciones no piden ámbitos innecesarios.
• Revisa periódicamente las aplicaciones empresariales registradas en Microsoft Entra ID para revocar tokens huérfanos o registros de aplicaciones que no se usan.
• Asegura la supervisión administrativa de cualquier flujo de credenciales de cliente que opere en entornos sin interfaz.

Conclusión

Entender la mecánica de la identidad en la nube moderna exige mirar más allá de los simples botones de inicio de sesión y examinar las estructuras de permisos subyacentes. Tanto si gestionas aplicaciones móviles orientadas al usuario con ámbitos delegados como grandes automatizaciones empresariales que dependen de permisos de aplicación, comprender estos límites es esencial para un entorno seguro de Microsoft 365.

Para profundizar en los fundamentos de cómo funcionan estos intercambios, escucha el episodio completo del podcast, con una explicación sin jerga de OAuth 2.0, los ciclos de vida de los tokens y los cuatro actores de cada intercambio.

Preguntas frecuentes

¿Pueden los usuarios normales aprobar permisos de aplicación en Microsoft Entra ID?

No. Los permisos de aplicación funcionan sin un usuario que haya iniciado sesión y tienen un alcance que abarca todo el inquilino. Por lo tanto, solo un administrador con los derechos adecuados del inquilino puede conceder permisos de aplicación.

¿Qué ocurre si un usuario intenta acceder a un archivo a través de una aplicación con permisos delegados para los que no tiene derechos?

La aplicación también tendrá bloqueado el acceso a ese archivo. Los permisos delegados toman prestada la identidad del usuario, por lo que la aplicación nunca puede superar los límites de acceso personales del usuario.

¿Cuál es el principal riesgo de seguridad de los permisos de aplicación?

Como los permisos de aplicación ejecutan servicios en segundo plano sin supervisión humana, una credencial de aplicación comprometida puede otorgar a un atacante acceso sin restricciones a los buzones, archivos y recursos de toda la empresa.

¿Cómo interactúa Microsoft Graph con los tokens de OAuth y los permisos?

Microsoft Graph funciona como puerta de enlace de API para Microsoft 365. Toda solicitud a Graph debe incluir un token de acceso OAuth que incorpore ámbitos específicos que definan permisos delegados o de aplicación.