Compartir a través de

Autorización de aplicaciones, recursos y cargas de trabajo con Microsoft Entra ID

  • Artículo

En este artículo se describe la autorización cuando un usuario individual interactúa y dirige una aplicación cuando las interfaces de programación de aplicaciones (API) actúan para un usuario. También abordamos los casos en que las aplicaciones o los servicios funcionan de forma independiente. Es el cuarto de una serie de artículos sobre cómo los desarrolladores de software independientes (ISV) pueden compilar y optimizar sus aplicaciones para Microsoft Entra ID. En esta serie, puede obtener más información sobre estos temas:

Autorización en aplicaciones

En esta sección, tratamos escenarios en los que un humano individual interactúa y dirige una aplicación. La sección Autorización en recursos (API) describe cómo las API realizan la autorización cuando el usuario necesita autorización para acceder a un recurso, pero Microsoft Entra ID no realiza la autorización final. La sección Autorización en cargas de trabajo trata escenarios en los que las aplicaciones o los servicios funcionan de forma independiente.

Las aplicaciones requieren las siguientes autorizaciones cuando necesitan acceder a los recursos de un usuario.

  • La aplicación debe tener autorización para acceder a operaciones específicas dentro de recursos específicos para el usuario actual.
  • El usuario debe tener autorización para acceder a un recurso en las condiciones actuales.
  • El usuario debe tener autorización para acceder a un recurso.

El proceso de autorización comienza con una aplicación que usa OAuth 2.0 para solicitar un token de acceso de Microsoft Entra ID para acceder a operaciones específicas dentro de un recurso específico para el usuario. En el acceso delegado una aplicación actúa como delegado para el usuario.

Para los desarrolladores, un recurso puede ser una API como Microsoft Graph, Azure Storage o su propia API. Sin embargo, la mayoría de las API tienen varias operaciones, como leer y escribir. Cuando una aplicación solo lee desde una API, una aplicación solo debe tener autorización para las operaciones de lectura. Este enfoque protege una aplicación frente a riesgos y su uso para obtener más acceso que el desarrollador previsto. El desarrollador sigue el principio de privilegios mínimos cuando su aplicación solo autoriza las operaciones que requiere.

Para designar qué operaciones específicas de una API específica requiere una aplicación, los desarrolladores usan el parámetro de ámbito de una solicitud de OAuth 2.0. El diseñador de API publica los ámbitos que una aplicación puede solicitar como parte del registro de aplicaciones de la API. Por ejemplo, los ámbitos del servicio Microsoft Power BI incluyen lo siguiente.

Ámbito del servicio Power BI Operations
https://analysis.windows.net/powerbi/api/Capacity.Read.All La aplicación puede ver todas las capacidades de Power BI Premium y Power BI Embedded a las que el usuario que ha iniciado sesión tiene acceso.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All La aplicación puede ver y editar todas las capacidades de Power BI Premium y Power BI Embedded a las que el usuario que ha iniciado sesión tiene acceso.

Si una aplicación solo lee las capacidades, la aplicación solicita el ámbitohttps://analysis.windows.net/powerbi/api/Capacity.Read.All. Si una aplicación edita la capacidad, la aplicación solicita el ámbitohttps://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All.

El ámbito contiene la identidad de la API y la identidad de la operación. En el ámbito https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All, la API es https://analysis.windows.net/powerbi/api. La operación es Capacity.ReadWrite.All. Dado el amplio alcance y popularidad de Microsoft Graph API, los desarrolladores pueden solicitar ámbitos para Microsoft Graph sin el componente de API del ámbito. Por ejemplo, Microsoft Graph define un ámbito de https://graph.microsoft.com/Files.Read que las aplicaciones pueden solicitar con Files.Read en lugar de usar el nombre de ámbito completo.

Para completar la primera autorización, una aplicación debe tener autorización para acceder a operaciones específicas dentro de recursos específicos para el usuario actual, Microsoft Entra ID debe autenticar primero al usuario actual. El inicio de sesión único (SSO) puede satisfacer esta autenticación o puede requerir una interacción de usuario nueva.

Una vez que Microsoft Entra ID determina al usuario, comprueba si el usuario autorizó la aplicación para el ámbito solicitado. Este proceso se denomina concesión de consentimiento. Si el usuario ha concedido consentimiento, el proceso de autorización puede continuar. El consentimiento del administrador permite a los usuarios administradores dar su consentimiento a sí mismos y a toda la organización. Microsoft Entra ID comprueba si la aplicación tiene el consentimiento del administrador para un ámbito. Si se concede, el proceso de autorización continúa.

Durante el diseño del ámbito, un diseñador de API puede designar ámbitos para los que solo un administrador puede dar su consentimiento. Los ámbitos que requieren consentimiento del administrador representan las operaciones que el diseñador de API considera más confidencial, eficaz o implica lo suficiente que un usuario no administrador no debe tener la autoridad para conceder a una aplicación.

Aunque los diseñadores de API tienen la primera palabra en la que sus ámbitos requieren el consentimiento del administrador, no tienen la última palabra. Cuando un diseñador de API designa que un ámbito requiere consentimiento del administrador, el ámbito siempre requiere el consentimiento del administrador. En el caso de los ámbitos que el diseñador de API no designa como requisito de consentimiento del administrador, el administrador de inquilinos puede requerir el consentimiento del administrador o consentimiento detallado basado en riesgos puede determinar el requisito de consentimiento del administrador. Los desarrolladores no pueden predecir si una solicitud de token requiere el consentimiento del administrador. Sin embargo, esta limitación no afecta al código necesario. La denegación de consentimiento es solo una de las muchas razones para la denegación de solicitud de token. Las aplicaciones siempre deben manipular correctamente no recibir un token.

Si el usuario o el administrador no han concedido consentimiento, el usuario ve una solicitud de consentimiento como se muestra en el ejemplo siguiente.

Captura de pantalla de la petición del consentimiento del usuario.

Las solicitudes de consentimiento del usuario administrador pueden permitirles seleccionar Consentimiento en nombre de su organización para conceder consentimiento a todos los usuarios del inquilino, como se muestra en el ejemplo siguiente.

Captura de pantalla del mensaje de consentimiento del administrador.

Las aplicaciones controlan el tiempo de las solicitudes de consentimiento del usuario. Microsoft Entra ID admite el consentimiento estático: cuando una aplicación usa el ámbito .default, la aplicación solicita todos los permisos declarados en el registro de la aplicación. Con el consentimiento estático, la aplicación solicita con antelación todos los permisos que podría necesitar.

El consentimiento estático puede desaconsejar a los usuarios y administradores de aprobar la solicitud de acceso de la aplicación. El procedimiento recomendado para el proceso de solicitud de consentimiento es solicitar permisos necesarios dinámicamente para la funcionalidad de línea base de la aplicación en el inicio de la aplicación y solicitar más ámbitos, cuando sea necesario. Solicite incrementalmente más ámbitos a medida que la aplicación realiza operaciones que requieren esos ámbitos. Este enfoque proporciona al usuario una mejor comprensión de otros permisos que se correlacionan con el tiempo de funcionalidad. Para cada token de acceso de API, Microsoft Entra ID incluye todos los ámbitos concedidos previamente a una aplicación y no solo los ámbitos de la solicitud.

Por ejemplo, una aplicación puede solicitar https://graph.microsoft.com/user.read para iniciar sesión en el usuario y acceder al perfil del usuario cuando se inicia la aplicación. Más adelante, un usuario selecciona Guardar en OneDrive y la aplicación solicita https://graph.microsoft.com/files.readwrite para escribir un archivo en OneDrive de los usuarios. Dado que el usuario ve por qué una aplicación pide que escriba en Su OneDrive, el usuario concede el permiso y la aplicación guarda un archivo en OneDrive del usuario. A continuación, el usuario cierra la aplicación. La próxima vez que se inicie la aplicación, solicita https://graph.microsoft.com/user.read. Microsoft Entra ID devuelve un token de acceso con ámbitos https://graph.microsoft.com/user.read y https://graph.microsoft.com/files.readwrite. Una solicitud de token para el ámbito https://graph.microsoft.com/files.readwrite no requiere consentimiento, ya que el usuario lo concedió. El almacenamiento en caché de tokens en Bibliotecas de autenticación de Microsoft (MSAL) controla automáticamente los tokens de almacenamiento en caché en función de los permisos concedidos. En este ejemplo, después del reinicio de la aplicación, llama a MSAL para adquirir un token con el ámbito https://graph.microsoft.com/files.readwrite devuelve el token almacenado en caché desde la solicitud inicial de la aplicación para el ámbito https://graph.microsoft.com/user.read. No se necesita otra llamada a Microsoft Entra ID.

El consentimiento dinámico e incremental no requiere permisos declarados durante el registro de la aplicación. Sin embargo, se recomienda encarecidamente que las aplicaciones declaren los permisos que una aplicación puede requerir en un registro de aplicación para admitir el consentimiento estático. Los administradores pueden conceder consentimiento de administrador en el Centro de administración de Microsoft Entra, mediante Microsoft Graph PowerShell, o con Microsoft Graph API.

Para conceder el consentimiento del administrador para una aplicación, el Centro de administración de Microsoft Entra usa el consentimiento estático solicitando consentimiento con el ámbito .default para una aplicación. Los administradores no pueden conceder consentimiento del administrador en el Centro de administración de Microsoft Entra a las aplicaciones que requieren permiso si los desarrolladores no los declaran en el registro de aplicaciones.

Los clientes de Microsoft Entra ID pueden usar Directivas de acceso condicional para proteger los recursos (API) y las aplicaciones basadas en explorador. De manera predeterminada, los administradores no pueden aplicar directivas de acceso condicional a las autenticaciones de aplicaciones nativas. Los administradores de inquilinos pueden tener como destino Todos los recursos (anteriormente "Todas las aplicaciones en la nube") o usar atributos de seguridad personalizados para dirigirse a aplicaciones nativas con directivas de acceso condicional. Incluso cuando se destina de otro modo, la aplicación de directivas no incluye algunas aplicaciones que acceden a Microsoft Graph o Azure AD Graph.

Normalmente, las aplicaciones no requieren código especial para el acceso condicional a menos que se apliquen los siguientes escenarios.

  • Aplicaciones que realizan el flujo en nombre de
  • Aplicaciones que acceden a varios servicios o recursos
  • Aplicaciones de página única que usan MSAL.js
  • Aplicaciones web que llaman a un recurso

Si la aplicación implementa cualquiera de estos escenarios, revise La guía para desarrolladores para el acceso condicional de Microsoft Entra.

Los inquilinos gratuitos de Microsoft Entra ID no pueden usar el acceso condicional (consulte requisitos de licencia. Es posible que el inquilino de producción de su empresa tenga las licencias necesarias. Evalúe estas condiciones antes de usar el inquilino de producción para realizar pruebas. Hay instrucciones para crear un inquilino de prueba.

De manera predeterminada, las directivas de acceso condicional se aplican a las aplicaciones y a los recursos a los que accede una aplicación en el nivel de aplicación. Los administradores de TI pueden aplicar directivas de nivel de aplicación a cualquier aplicación sin participación del desarrollador. Algunas aplicaciones y escenarios requieren más granularidad. Por ejemplo, una aplicación financiera puede requerir autenticación multifactor para uso típico. Sin embargo, una transacción a través de una cantidad designada puede requerir un dispositivo administrado. Los desarrolladores pueden permitir que los administradores de TI asignen directivas de acceso condicional paso a paso a diferentes áreas de una aplicación mediante la implementación Contexto de autenticación de acceso condicional. La Guía del desarrollador para el contexto de autenticación de acceso condicional es una buena referencia para estas características.

De manera predeterminada, Microsoft Entra ID emite tokens de acceso que son válidos para una hora establecida. Las aplicaciones nunca deben asumir la longitud de la duración. Deben usar el parámetro expires_in que devuelve Microsoft Entra ID con el token de acceso. MSAL manipula automáticamente este escenario. Durante la vigencia del token de acceso, el usuario tiene autorización para acceder al recurso en las condiciones en el momento de la autorización.

El retraso entre cuándo cambian las condiciones y cuándo se produce la aplicación de cambios de directiva puede preocupar a los administradores y usuarios. Por ejemplo, cuando un usuario pierde un dispositivo, el administrador de TI puede revocar las sesiones del usuario. Sin embargo, una aplicación del dispositivo perdido puede seguir accediendo a Microsoft Graph para el usuario hasta que expire el token. Microsoft evaluación continua del acceso (CAE) puede impedir el acceso después de la revocación de sesiones de usuario para las aplicaciones que adoptan CAE. Si la aplicación llama a Microsoft Graph al menos una vez por hora, puede adoptar CAE. Cómo usar las API habilitadas para la evaluación continua de acceso en las aplicaciones proporciona detalles de implementación.

Si no se puede compilar en MSAL, la aplicación debe usar OAuth 2.0 para solicitar tokens de acceso desde Microsoft Entra ID. La plataforma de identidad de Microsoft y el flujo de código de autorización de OAuth 2.0 proporcionan detalles de implementación para los flujos que admite Microsoft Entra ID.

Si compila aplicaciones de dispositivos móviles, revise Compatibilidad con el inicio de sesión único y las directivas de protección de aplicaciones en aplicaciones móviles. Aprenda a admitir la adquisición de tokens, Administración de aplicaciones móviles de Intune (MAM) y directivas de protección de aplicaciones.

Autorización en recursos (API)

La sección Autorización en aplicaciones introdujo tres autorizaciones necesarias cuando las aplicaciones necesitan acceder a los recursos de un usuario, pero solo se trataron las dos primeras. El usuario debe tener autorización para acceder a un recurso, pero Microsoft Entra ID no realiza la autorización final. El recurso (API) realiza la autorización.

Las API deben exigir dos autorizaciones al actuar para un usuario:

  • Las API deben autorizar a una aplicación para llamar a la API. Compruebe que la notificación scp (ámbito) del token de acceso contiene el ámbito necesario.
  • Las API deben autorizar al usuario a acceder al recurso específico. Las notificaciones oid (Id. de objeto) y sub (asunto) del token representan la identidad del usuario.

Se recomiendan las notificaciones oid y sub para la autorización.

Microsoft Entra ID implementa una notificación sub en pares, por lo que la notificación de sub es un identificador de usuario único para la aplicación solicitante. El mismo usuario que usa una aplicación diferente tiene una notificación sub diferente. La notificación oid es constante para el usuario para todas las aplicaciones.

Las aplicaciones proporcionan el token de acceso necesario a las API que Microsoft Entra ID protege en el encabezado de autorización de solicitud de http como token de portador. Las API deben validar completamente el token recibido porque el token no procede directamente de Microsoft Entra ID. Considere la aplicación que llama como no confiable hasta la validación del token. Los artículos de referencia de token de acceso y referencia de validación de notificaciones proporcionan detalles sobre la validación de tokens de acceso de Id. de Microsoft Entra.

Microsoft Entra ID publica las claves públicas que usan las API para validar la firma del token. Estas claves se reponen periódicamente y siempre que la situación requiera sustitución de claves públicas. La aplicación nunca debe asumir una programación establecida para la sustitución de claves públicas. Sustitución de claves de firma en la plataforma de identidad de Microsoft explica cómo controlar correctamente la sustitución de claves públicas.

Se recomienda usar una biblioteca bien mantenida para realizar la validación de tokens. Si va a compilar una aplicación web o API en ASP.NET o ASP.NET Core, use Microsoft.Identity.Web para controlar la validación de tokens. En el artículo Procedimientos de API web protegida se explica cómo usar Microsoft.Identity.Web para proteger una API.

A veces, las API necesitan llamar a otras API. Cuando una aplicación funciona para el usuario, la API recibe un token de acceso delegado que incluye la identidad del usuario actual. Es importante que la API confíe solo en un token validado de Microsoft Entra ID para determinar la identidad del usuario actual. Este enfoque impide que la aplicación ponga en peligro de modo que los usuarios suplantan a otros usuarios y accedan a los recursos de otro usuario. Para esta misma protección cuando una API llama a otra API, use el flujo en nombre de OAuth para adquirir un token de acceso para llamar a una API para el usuario al que se llamó a la API. Compilación de una API web que llama a las API web proporciona pasos para que una API llame a otras API para el usuario de la aplicación actual.

Además del acceso delegado, es posible que las API necesiten admitir aplicaciones y actuar de forma independiente sin los usuarios actuales. Microsoft Entra ID hace referencia a estas aplicaciones como cargas de trabajo. Para aplicar la autorización de carga de trabajo, las API no usan la notificación scp (ámbito). En su lugar, las API usan la notificación roles para validar que la carga de trabajo tiene el consentimiento necesario. Las API son responsables de exigir que la carga de trabajo tenga autorización para acceder al recurso.

Autorización en cargas de trabajo

Las cargas de trabajo son aplicaciones que funcionan de forma independiente y no tienen un usuario actual. Al igual que el acceso delegado descrito en la sección Autorización en aplicaciones, acceso solo a la aplicación requiere varias autorizaciones:

  • La aplicación debe tener autorización para acceder a operaciones específicas dentro de recursos específicos.
  • La aplicación debe tener autorización para acceder al recurso en las condiciones actuales.
  • La aplicación debe tener autorización para acceder al recurso.

El proceso comienza con una carga de trabajo que solicita un token de acceso con el ámbito .default (por ejemplo, https://graph.microsoft.com/.default). A diferencia del acceso delegado (las aplicaciones pueden solicitar de forma dinámica e incremental), las cargas de trabajo siempre deben usar el consentimiento estático y el ámbito .default.

Los diseñadores de API crean permisos de aplicación para su API agregando roles al registro de aplicaciones de la API. Estos roles tienen un tipo de miembro permitido de aplicaciones, que permite la asignación de roles a cargas de trabajo. Asignar roles a cargas de trabajo en el Centro de administración de Microsoft Entra o con Microsoft Graph. En el Centro de administración de Microsoft Entra, el consentimiento del administrador de los roles asignados es necesario antes de que se pueda ejecutar la carga de trabajo.

De manera predeterminada, un permiso de aplicación autoriza a las cargas de trabajo a acceder a todas las instancias de un recurso. Por ejemplo,https://graph.microsoft.com/user.read.all autoriza una carga de trabajo para acceder al perfil de usuario completo de todos los usuarios del inquilino. A menudo, los administradores de TI son reticentes a conceder estos permisos amplios.

En el caso de las cargas de trabajo que acceden a Microsoft Graph, use estos métodos para limitar el permiso de aplicación:

A diferencia de las aplicaciones con usuarios, las cargas de trabajo se autentican en Microsoft Entra ID.

En el caso de las cargas de trabajo que se ejecutan en Microsoft Azure, el mejor método para que una carga de trabajo se autentique es identidades administradas para recursos de Azure. La característica identidades administradas elimina la necesidad de administrar las credenciales de la carga de trabajo. No hay credenciales accesibles. Microsoft Entra ID administra completamente las credenciales. Sin credenciales para administrar, no hay credenciales en riesgo.

Con una mayor seguridad, las identidades administradas también aumentan la resistencia. Las identidades administradas usan tokens de acceso de larga duración e información de Microsoft Entra ID para obtener nuevos tokens antes de que expiren los tokens. Las identidades administradas usan puntos de conexión regionales que ayudan a evitar errores fuera de la región mediante la consolidación de dependencias de servicio. Los puntos de conexión regionales ayudan a mantener el tráfico en un área geográfica. Por ejemplo, si los recursos de Azure están en WestUS2, todo el tráfico permanecerá en WestUS2.

Si la carga de trabajo no se ejecuta en Microsoft Azure, la carga de trabajo debe autenticarse con el Flujo de credenciales de cliente de OAuth 2.0.

Microsoft Entra ID admite estos tipos de credenciales de cliente:

  • Certificado. Las cargas de trabajo demuestran que tienen posesión de una clave privada mediante la firma de una aserción con la clave privada. La clave privada no se transmite a Microsoft Entra ID. Solo se envía la aserción. Recomendamos certificados en lugar de secretos de cliente, ya que son más seguros y a menudo se administran mejor.
  • Credencial federada. La federación de identidades de carga de trabajopermite que las cargas de trabajo que no se ejecutan en Microsoft Azure usen una identidad de otro proveedor de identidades, Acciones de GitHub o clúster de Kubernetes. Las cargas de trabajo solicitan tokens de la misma manera para las credenciales federadas que para las credenciales de certificado. La diferencia es que la aserción, un token web JSON firmado, procede del proveedor de identidades de federación.
  • Secreto de cliente. A veces se denomina contraseña de aplicación, un secreto de cliente es un valor de cadena que la carga de trabajo puede usar para identificarse. El valor de texto del secreto se envía desde la carga de trabajo al identificador de Microsoft Entra en una Solicitud POST para un token. Los secretos de cliente son menos seguros que los certificados o la federación de identidad de carga de trabajo. Si la carga de trabajo usa secretos, siga estos procedimientos recomendados para administrar secretos.

Además del id. de Microsoft Entra, la familia de productos de Microsoft Entra incluye Identificador de carga de trabajo de Microsoft Entra. El identificador de carga de trabajo de Microsoft Entra tiene las siguientes características premium para mejorar la seguridad de la carga de trabajo.

  • Acceso condicional admite directivas basadas en ubicaciones o riesgos para identidades de carga de trabajo.
  • Protección de id. de Microsoft Entra proporciona informes sobre credenciales en peligro, inicios de sesión anómalos y cambios sospechosos en las cuentas.
  • Revisiones de acceso habilita la delegación de revisión a las personas adecuadas, centradas en los roles con privilegios más importantes.
  • Recomendaciones de estado de la aplicación sugerir formas de abordar las brechas de higiene de identidades en la cartera de aplicaciones y mejorar la seguridad y la posición de resistencia de los inquilinos.

Las cargas de trabajo pueden admitir Evaluación continua de acceso (CAE) si llaman a Microsoft Graph al menos una vez por hora. Para admitir CAE, la carga de trabajo debe ser una aplicación de inquilino único y la aplicación registrada en el inquilino donde accede a Microsoft Graph. Si la carga de trabajo cumple estos requisitos, consulte este de ejemplo para conocer los pasos de implementación.

Pasos siguientes