Desmitificando OAuth 2.0 en Microsoft Graph: permisos delegados frente a permisos de aplicación

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

¡Bienvenido de nuevo al blog! Si te has sumergido a fondo en la automatización de Microsoft 365, seguramente te hayas topado con los límites que imponen los conectores nativos y los tradicionales …

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

¡Bienvenido de nuevo al blog! Si te has adentrado a fondo en la automatización de Microsoft 365, seguramente te hayas topado con los límites que imponen los conectores nativos y las limitaciones de los scripts tradicionales. Navegar por la complejidad de la autenticación puede resultar complicado al automatizar M365, sobre todo cuando intentas equilibrar una seguridad sólida con una funcionalidad fluida. Ya sea que estés creando aplicaciones empresariales personalizadas o configurando procesos automatizados en segundo plano, entender bien los modelos de autenticación es fundamental. Este artículo desglosa los tokens, los ámbitos y los flujos de consentimiento para ayudarte a elegir el modelo adecuado, ya sea para tareas centradas en el usuario o para procesos desatendidos en segundo plano. Vamos directamente al grano y desmitifiquemos cómo OAuth 2.0 impulsa la API de Microsoft Graph.

Introducción a la autenticación en Microsoft Graph

Microsoft Graph es la puerta de enlace unificada a todo el ecosistema de Microsoft 365. En lugar de interactuar con API independientes y fragmentadas para Exchange, SharePoint, Teams y Azure Active Directory (ahora Microsoft Entra ID), los desarrolladores y los administradores de TI pueden acceder a todos estos servicios a través de un único punto de conexión. Sin embargo, como Graph controla el acceso a datos corporativos sensibles, proteger esta puerta de enlace requiere un marco de autenticación estricto. Entender cómo se relacionan la identidad, los tokens de acceso y los permisos es el primer paso para crear automatizaciones fiables y seguras que no se rompan bajo presión ni activen alertas de seguridad.

Comprender OAuth 2.0 en el contexto de Microsoft 365

En su esencia, Microsoft Graph se basa en el protocolo OAuth 2.0 para la autorización. Cuando tu aplicación o script quiere comunicarse con Graph, no puede simplemente enviar las credenciales en texto plano. En su lugar, debe solicitar un token de acceso a la plataforma de identidad de Microsoft (Entra ID). Este token de acceso actúa como un pasaporte digital seguro. Indica a Microsoft Graph quién realiza la solicitud, qué aplicación se está usando y, lo más importante, qué permisos específicos (ámbitos) se han concedido a ese token. Sin un token válido, Graph rechazará inmediatamente la solicitud con un error estándar de no autorizado.

Permisos delegados: cuándo ejecutar en nombre del usuario

La elección del modelo de permisos adecuado depende por completo de la naturaleza de tu carga de trabajo. Los permisos delegados están diseñados para aplicaciones que se ejecutan con el respaldo de un usuario que ha iniciado sesión. Cuando una aplicación usa permisos delegados, actúa en nombre del usuario que está conectado activamente. Si un usuario ejecuta un script para leer su propio calendario o actualizar su foto de perfil, Graph evalúa la solicitud no solo en función de lo que la aplicación tiene permitido hacer, sino también de lo que ese usuario concreto tiene permiso para acceder. Si el usuario no tiene permiso para ver un buzón específico, el token delegado tampoco lo concederá. Este modelo es ideal para aplicaciones orientadas al usuario, herramientas interactivas y scripts de productividad personal.

Permisos de aplicación: impulsar procesos desatendidos en segundo plano

Por el contrario, ¿qué ocurre cuando necesitas ejecutar un script o un servicio a medianoche sin que ningún usuario esté frente al teclado? Para procesos desatendidos en segundo plano, servicios daemon e informes de todo el inquilino, necesitas permisos de aplicación. En este modelo, la aplicación funciona de forma independiente de cualquier contexto de usuario: se ejecuta con su propia identidad. Como no hay un usuario humano que inicie sesión y conceda el consentimiento de forma interactiva, los permisos de aplicación requieren una autorización previa explícita por parte de un administrador del inquilino. Una vez concedidos, la aplicación puede acceder a los datos de toda la organización, lo que convierte este modelo en una herramienta excepcionalmente potente para la automatización administrativa, los scripts de incorporación y la supervisión de cumplimiento, pero también exige una supervisión de seguridad estricta.

Navegar por los ámbitos, los tokens y los flujos de consentimiento

La terminología de autenticación y autorización puede resultar abrumadora, pero desglosar el flujo de trabajo aclara el proceso. Los ámbitos son los permisos específicos que tu aplicación solicita, como User.Read.All o Mail.Read. Cuando un usuario o un administrador autoriza una aplicación, está revisando y aprobando esos ámbitos. Una vez aprobados, la plataforma de identidad emite un token web JSON (JWT). Tu código incluye este token en el encabezado HTTP Authorization de cada solicitud que envías a Microsoft Graph. Gestionar bien el consentimiento garantiza que tu aplicación pueda obtener estos tokens sin problemas y sin encontrarse con obstáculos inesperados.

Cómo evitar el purgatorio del consentimiento de administrador

Uno de los puntos de fricción más comunes para desarrolladores y administradores es quedarse esperando una aprobación administrativa. Cuando una aplicación solicita ámbitos de aplicación con privilegios elevados o ámbitos delegados sensibles, Microsoft Entra ID puede exigir que un administrador consienta la aplicación antes de que se pueda emitir cualquier token. Si tu canal de implementación da por hecho que los usuarios pueden dar su propio consentimiento y, de repente, las directivas del inquilino les bloquean, tu automatización se detiene por completo. Para evitar el purgatorio del consentimiento de administrador, planifica siempre los permisos necesarios desde el principio, documenta la justificación empresarial y coordínate con tus administradores globales o de aplicaciones para preconfigurar el consentimiento en todo el inquilino cuando sea necesario.

Errores comunes y cómo solucionarlos

Incluso los desarrolladores con experiencia se topan a veces con obstáculos de autorización frustrantes al trabajar con Microsoft Graph. Veamos algunos problemas habituales y cómo resolverlos:

• Funciona en mi equipo, falla en los demás: suele deberse a un consentimiento que falta o a ámbitos incorrectos. Solución: documenta con claridad los ámbitos necesarios y configura el consentimiento de administrador en todo el inquilino cuando proceda.
• Descarga excesiva de datos: obtener listas completas de usuarios sin filtrar provoca tiempos de espera y limitación. Solución: usa $select, $top, la paginación y las consultas delta.
• Bucles infinitos de 401/403: suelen deberse a un token caducado o a usar un tipo de permiso delegado para un trabajo sin usuario. Solución: implementa una renovación de tokens sólida y cambia a permisos de aplicación para las tareas en segundo plano.
• Alcanzar los límites de frecuencia: recibir respuestas 429 significa que estás enviando solicitudes demasiado rápido. Solución: implementa un retroceso exponencial, respeta el encabezado Retry-After y agrupa las operaciones en lotes.
• Proliferación de secretos: codificar de forma fija los secretos de cliente en los scripts es un riesgo de seguridad enorme. Solución: utiliza Azure Key Vault, identidades administradas o variables de entorno seguras.

Mejores prácticas de seguridad y gobernanza

Cuando abres la puerta de tu inquilino de Microsoft 365 mediante una API, la seguridad debe ser tu prioridad absoluta. Aplicar el principio de privilegio mínimo significa que solo debes solicitar los ámbitos mínimos imprescindibles para que tu aplicación funcione; nunca solicites Directory.AccessAsUser.All solo para leer el nombre para mostrar de un usuario. Mantén un registro de consentimientos claro que detalle qué aplicaciones tienen acceso a tu inquilino, aísla por completo los registros de aplicaciones de desarrollo, pruebas y producción, y establece un calendario estricto para rotar los secretos de cliente y los certificados.

Tus primeras consultas reales (ejemplos)

Una vez que tu modelo de autenticación esté bien definido, puedes empezar a ejecutar consultas contra la API de Graph. Aquí tienes algunos ejemplos prácticos que puedes adaptar:

• Nuevas incorporaciones desde una fecha:
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• Mis próximas reuniones:
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• Miembros de un grupo:
  GET /groups/{group-id}/members?$select=id,displayName,mail
• Usuarios modificados (delta):
  GET /users/delta?$select=id,displayName,mail

Herramientas recomendadas

Usar las herramientas adecuadas facilita mucho la creación y la depuración de consultas de Microsoft Graph. Graph Explorer es un entorno de pruebas web muy valioso para probar endpoints y comprobar las sugerencias de consentimiento. Para escribir código, los SDK de Microsoft Graph (.NET, JavaScript, Python) abstraen gran parte de la lógica HTTP subyacente. Postman o las extensiones REST Client de tu IDE son excelentes para gestionar colecciones y entornos, mientras que Power Automate, Logic Apps y PowerShell se encargan de la automatización visual y operativa del flujo de trabajo con gran eficacia.

Preguntas frecuentes

¿Delegado o de aplicación? ¿Cómo elijo?

Las tareas centradas en el usuario se asocian mejor con los permisos delegados. Los trabajos desatendidos, los daemons en segundo plano y las tareas administrativas amplias requieren permisos de aplicación combinados con el consentimiento de administrador correspondiente.

¿Cómo evito la limitación de solicitudes (throttling)?

Usa $select para limitar el tamaño de las cargas, implementa la paginación y las consultas delta, agrupa las solicitudes en lotes siempre que sea posible y diseña siempre tus scripts para gestionar con elegancia los códigos de estado 429 con una lógica de reintentos.

¿Puedo usar Graph sin programar?

¡Sí! Puedes crear prototipos de endpoints en Graph Explorer y orquestar flujos de trabajo con Power Automate. Para una lógica más compleja, da el salto a los SDK oficiales o a los scripts de PowerShell.

¿Es Graph lo bastante seguro para los informes de cumplimiento?

Sin duda. Cuando se implementa siguiendo el principio de mínimo privilegio, con registro centralizado, flujos de consentimiento auditados y una gestión segura de secretos, Microsoft Graph cumple con los rigurosos estándares de cumplimiento normativo de las empresas.

Conclusión

Dominar la autenticación en Microsoft Graph es la clave definitiva para cualquier administrador, arquitecto o desarrollador que quiera aprovechar de verdad el potencial de Microsoft 365. Al entender la diferencia fundamental entre los permisos delegados y los de aplicación, gestionar con cuidado los ámbitos y los tokens, y seguir una gobernanza de seguridad estricta, podrás crear automatizaciones que sean a la vez potentes y seguras. Para profundizar aún más en este tema, explorar ejemplos de código y conocer estrategias avanzadas para la gestión de errores y la limitación de solicitudes, no dejes de consultar el episodio de podcast relacionado: Automate Microsoft 365 with Microsoft Graph API. ¡Feliz automatización!