Adquisición de autorización para acceder a los recursos
Este artículo le ayuda, como desarrollador, a comprender cómo asegurarse de que Confianza cero al adquirir permisos de acceso a recursos para la aplicación. Para acceder a recursos protegidos, como el correo electrónico o los datos del calendario, la aplicación necesita la autorización del administrador del recurso. El propietario del recurso puede dar su consentimiento o denegar la solicitud de la aplicación. La aplicación recibe un token de acceso cuando el propietario del recurso concede consentimiento; la aplicación no recibe un token de acceso cuando el propietario del recurso deniega el acceso.
Revisión conceptual
Puede usar el Plataforma de identidad de Microsoft para autenticar y autorizar las aplicaciones y administrar permisos y consentimientos. Comencemos revisando algunos conceptos:
La autenticación (a veces abreviada AuthN) es el proceso de demostrar que la identidad reclamada es precisa. La plataforma de identidad de Microsoft usa el protocolo OpenID Connect para administrar la autenticación. La autorización (a veces abreviada AuthZ) concede permiso para hacer algo a una parte autenticada. Especifica a qué datos puede acceder la parte autenticada. La Plataforma de identidad de Microsoft usa el protocolo OAuth2.0 para administrar la autorización. Entre las opciones de autorización se incluyen listas de control de acceso (ACL), control de acceso basado en roles y control de acceso a atributos (ABAC). La autenticación suele ser un factor de autorización.
Acceso delegado (actuando en nombre de un usuario que ha iniciado sesión) o acceso directo (actuando solo como identidad propia de la aplicación) permite que la aplicación acceda a los datos. El acceso delegado requiere permisos delegados (también conocidos como ámbitos). Además, el cliente y el usuario deben estar autorizados por separado para realizar la solicitud. Acceso directo podría requerir permisos de aplicación (también conocidos como roles de aplicación); cuando se conceden roles de aplicación a las aplicaciones, se pueden llamar permisos de aplicaciones.
Los permisos delegados, usados con el acceso delegado, permiten a una aplicación actuar en nombre de un usuario y acceder solo a lo que el usuario puede acceder. El permiso de aplicación, usado con el acceso directo, permite a una aplicación acceder a todos los datos con los que está asociado el permiso. Solo los administradores o propietarios de las entidades de servicio pueden dar su consentimiento a los permisos de aplicación.
Consentimiento es la manera en que las aplicaciones reciben permisos. Los usuarios o administradores autorizan a una aplicación a acceder a un recurso protegido. Una petición de consentimiento muestra los permisos que solicita la aplicación y la información del publicador.
La autenticación previa es la manera en que los propietarios de aplicaciones de recursos conceden acceso a las aplicaciones cliente. Pueden hacerlo en el portal de Azure o mediante PowerShell y las API como Microsoft Graph. Pueden conceder permisos de recursos sin necesidad de que los usuarios vean un aviso de consentimiento para el conjunto de permisos de autenticados previamente.
Diferencias entre permisos delegados y permisos de aplicación
Las aplicaciones funcionan en dos modos: cuando un usuario está presente (permiso delegado) y cuando no hay ningún usuario (permiso de aplicación). Cuando hay un usuario delante de una aplicación, se le obliga a actuar en nombre de ese usuario; no debe actuar en nombre de la propia aplicación. Cuando un usuario dirige la aplicación, usted actúa como delegado para ese usuario. Obtiene permiso para actuar en nombre del usuario que identifica el token.
Las aplicaciones de tipo de servicio (tareas en segundo plano, demonios, procesos de servidor a servidor, etc.) no tienen usuarios que puedan identificarse o escribir una contraseña. Requieren un permiso de aplicación para actuar en nombre propio (en nombre de la aplicación de servicio).
Procedimientos recomendados para la autorización de aplicaciones de Confianza cero
El enfoque de autorización tiene autenticación como componente cuando se conecta a un usuario presente a la aplicación y al recurso que está llamando. Cuando la aplicación actúa en nombre de un usuario, no confiamos en la aplicación que realiza la llamada para indicarnos quién es el usuario ni dejamos que la aplicación decida quién es. Microsoft Entra ID comprueba y proporciona directamente información sobre el usuario en el token.
Cuando necesite permitir que la aplicación llame a una API o autorizar a la aplicación para que pueda acceder a un recurso, los esquemas de autorización modernos pueden requerir la autorización mediante un marco de permisos y consentimiento. Consulte el artículo Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID, que describe el URI de redireccionamiento, los tokens de acceso (usados para flujos implícitos), los certificados y los secretos, el identificador URI de la aplicación y la propiedad de la aplicación.
Pasos siguientes
- Personalizar tokens describe la información que puede recibir en tokens de Microsoft Entra. Explica cómo personalizar tokens para mejorar la flexibilidad y el control, al tiempo que aumenta la seguridad de confianza cero de la aplicación con privilegios mínimos.
- Configurar notificaciones de grupo y roles de aplicación en tokens muestra cómo configurar las aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a roles de aplicación. Estos métodos ayudan a mejorar la flexibilidad y el control, al tiempo que aumentan la seguridad de confianza cero de la aplicación con privilegios mínimos.
- Desarrollar estrategia de permisos delegados le ayuda a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar mediante principios de confianza cero.
- Desarrollar la estrategia de permisos de aplicación le ayuda a decidir sobre el enfoque de permisos de aplicación para la administración de credenciales.
- Proporcionar credenciales de identidad de aplicación cuando no hay ningún usuario explica por qué Identidades administradas para recursos de Azure es la mejor práctica de credenciales de cliente para servicios (aplicaciones que no son de usuario) en Azure.
- Procedimientos recomendados de autorización le ayuda a implementar los mejores modelos de autorización, permisos y consentimiento para las aplicaciones.
- Use los procedimientos recomendados de desarrollo para la administración de identidad y acceso de Confianza cero en el ciclo de vida de desarrollo de las aplicaciones para crear aplicaciones seguras.
- El artículo Creación de aplicaciones con un enfoque de Confianza cero para la identidad continúa a partir del artículo Procedimientos recomendados de desarrollo para la administración de identidad y acceso de Confianza cero para ayudarle a usar un enfoque de Confianza cero para la identidad en el ciclo de vida de desarrollo de software (SDLC).