Adquisición de autorización para acceder a los recursos

Este artículo le ayuda, como desarrollador, a comprender cómo garantizar mejor 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 propietario 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 la plataforma de identidad de Microsoft para autenticar y autorizar las aplicaciones y administrar permisos y consentimiento. Comencemos con algunos conceptos:

• La autenticación (a veces abreviada en AuthN) es el proceso de demostrar que la identidad reclamada es precisa. La plataforma de identidad de Microsoft usa el protocolo OpenID Connect para controlar la autenticación. La autorización (a veces abreviada en AuthZ) concede a una entidad autenticada permiso para hacer algo. Especifica a qué datos puede tener acceso el usuario autenticado. La plataforma de identidad de Microsoft usa el protocolo OAuth2.0 para controlar la autorización. Entre las opciones de autorización se incluyen listas de control de acceso (ACL), control de acceso basado en rol y control de acceso a atributos (ABAC). La autenticación suele ser un factor de autorización.

• El acceso delegado (que actúa en nombre de un usuario que ha iniciado sesión) o el acceso directo (que solo actúa 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). El cliente y el usuario deben estar autorizados por separado para realizar la solicitud. El acceso directo puede requerir permisos de aplicación (también conocidos como roles de aplicación). Cuando las aplicaciones reciben roles de aplicación, se pueden llamar permisos de aplicaciones.

• Los permisos delegados, que se usan con acceso delegado, permiten que una aplicación actúe en nombre de un usuario, accediendo solo a lo que el usuario puede acceder. El permiso de aplicación, que se usa con acceso directo, permite a una aplicación acceder a los datos con los que está asociado el permiso. Solo los administradores y propietarios de las entidades de servicio pueden dar su consentimiento a los permisos de aplicación.

• El 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. Un mensaje de consentimiento muestra los permisos que requiere la aplicación junto con 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 Azure Portal o con PowerShell y 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 autenticados previamente .

Diferencia entre el permiso delegado y el permiso 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 debería actuar en nombre de la propia aplicación. Cuando un usuario dirige la aplicación, actúa como delegado para ese usuario. Estás obteniendo permiso para actuar en nombre del usuario que identifica el token.

Las aplicaciones de servicio (tareas en segundo plano, dæmons, procesos de servidor a servidor) 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 de autorización de aplicaciones de Confianza cero

El enfoque de autorización tiene la autenticación como un componente cuando te conectas con un usuario presente en la aplicación y al recurso que estás llamando. Cuando la aplicación actúa en nombre de un usuario, no confíamos en una aplicación que realiza una llamada para indicarnos quién es el usuario o permitir que la aplicación decida quién es el usuario. 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 autorice la aplicación para que la aplicación pueda acceder a un recurso, los esquemas de autorización modernos pueden requerir autorización a través de un marco de permisos y consentimiento. Consulte Los procedimientos recomendados de seguridad para las propiedades de la aplicación que incluyen URI de redirección, tokens de acceso (que se usan para flujos implícitos), certificados y secretos, URI de identificador de aplicación y propiedad de la aplicación.

Pasos siguientes

• Personalizar tokens describe la información que puede recibir en tokens de Microsoft Entra. Se 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 reclamaciones de grupo y roles de aplicación en tokens muestra cómo configurar tus aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a los 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 la estrategia de permisos delegados le ayuda a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar con 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.
• La creación de aplicaciones con un enfoque de confianza cero para la identidad continúa desde el artículo Procedimientos recomendados de desarrollo de identidades y administración de 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).