Solicitud de permisos mediante consentimiento

  • Artículo

Las aplicaciones de la Plataforma de identidad de Microsoft dependen del consentimiento para poder acceder a los recursos o las API necesarios. Los distintos tipos de consentimiento son mejores para diferentes escenarios de aplicación. Elegir el mejor enfoque para dar su consentimiento a la aplicación le ayudará a tener más éxito con los usuarios y las organizaciones.

En este artículo, obtendrá información sobre los distintos tipos de consentimiento y cómo solicitar permisos para la aplicación mediante consentimiento.

En el escenario del consentimiento estático del usuario, debe especificar todos los permisos que necesita en la configuración de la aplicación en el Centro de administración Microsoft Entra. Si al usuario o al administrador, según corresponda, no se le concede permiso para esta aplicación, la Plataforma de identidad de Microsoft pedirá al usuario que proporcione su consentimiento en este momento.

Los permisos estáticos también permiten a los administradores dar su consentimiento en nombre de todos los usuarios de la organización.

Aunque se basan en el consentimiento estático y en una lista de permisos única donde el código es sencillo y está bien organizado, la aplicación solicitará todos los permisos necesarios por adelantado. Esto puede impedir que los usuarios y administradores aprueben la solicitud de acceso a la aplicación.

Con el punto de conexión de la Plataforma de identidad de Microsoft, puede ignorar los permisos estáticos definidos en la información de registro de la aplicación en el Centro de administración Microsoft Entra. En su lugar, puede solicitar permisos de forma incremental. Puede solicitar un conjunto mínimo de permisos por adelantado y solicitar más con el tiempo, a medida que el cliente utilice las funciones adicionales de la aplicación. Para ello, puede especificar los ámbitos que la aplicación necesita en cualquier momento incluyendo los nuevos ámbitos en el parámetro scope cuando solicite un token de acceso. No es necesario predefinirlos en la información de registro de la aplicación. Si el usuario aún no ha dado su consentimiento a los ámbitos nuevos que se agregan a la solicitud, se le pedirá que dé su consentimiento solo a los nuevos permisos. El consentimiento incremental o dinámico solo se aplica a los permisos delegados y no a los permisos de la aplicación.

Permitir que una aplicación solicite permisos dinámicamente mediante el parámetro scope da a los desarrolladores un control total sobre la experiencia del usuario. También puede adelantar la experiencia de consentimiento y pedir todos los permisos en una solicitud de autorización inicial. Si su aplicación requiere un gran número de permisos, puede elegir recopilarlos del usuario de forma incremental, a medida que intentan usar determinadas características de la aplicación con el tiempo.

Importante

El consentimiento dinámico puede ser cómodo, pero presenta un gran desafío para los permisos que requieren consentimiento del administrador. La experiencia de consentimiento del administrador de las hojas Registros de aplicaciones y Aplicaciones empresariales del portal no tiene conocimiento de esos permisos dinámicos en tiempo de consentimiento. Se recomienda que un desarrollador enumere todos los permisos con privilegios de administrador que necesita la aplicación en el portal. Esto permite a los administradores de inquilinos dar su consentimiento en nombre de todos los usuarios del portal, una vez. Los usuarios no tendrán que pasar por la experiencia de consentimiento para esos permisos al iniciar sesión. La alternativa es usar el consentimiento dinámico para esos permisos. Para conceder el consentimiento del administrador, un administrador individual inicia sesión en la aplicación, desencadena una solicitud de consentimiento para los permisos adecuados y selecciona el consentimiento para toda la organización en el cuadro de diálogo de consentimiento.

En una solicitud de autorización de OpenID Connect o OAuth 2.0, una aplicación puede solicitar los permisos que necesita mediante el parámetro de consulta scope. Por ejemplo, cuando un usuario inicia sesión en una aplicación, la aplicación envía una solicitud como la del ejemplo siguiente. (Se han agregado saltos de línea para mejorar la legibilidad).

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

El parámetro scope es una lista separada por espacios que incluye los permisos delegados que la aplicación solicita. Cada permiso se indica anexando el valor del permiso al identificador del recurso (URI del identificador de aplicación). En la solicitud de ejemplo, la aplicación necesita permiso para leer el calendario del usuario y enviar correo electrónico en nombre del usuario.

Después de que el usuario escriba sus credenciales, la Plataforma de identidad de Microsoft buscará un registro que coincida con el consentimiento del usuario. Si el usuario no dio su consentimiento a ninguno de los permisos solicitados en el pasado, y si el administrador no dio su consentimiento a estos permisos en nombre de toda la organización, la Plataforma de identidad de Microsoft solicita al usuario que conceda los permisos solicitados.

En el ejemplo siguiente, los permisos offline_access ("Mantener el acceso a los datos a los que se le ha dado acceso") y User.Read ("Iniciar sesión y leer su perfil") se incluyen automáticamente en el consentimiento inicial para una aplicación. Estos permisos son necesarios para que la aplicación funcione correctamente. El permiso offline_access concede a la aplicación acceso a los tokens de actualización que son críticos para aplicaciones nativas y aplicaciones web. El permiso User.Read concede acceso a la notificación sub. Permite al cliente o a la aplicación identificar correctamente al usuario con el tiempo y acceder a información de usuario rudimentaria.

Captura de pantalla de ejemplo que muestra el consentimiento de la cuenta profesional

Cuando el usuario aprueba la solicitud del permiso, el consentimiento se registra. No es necesario que el usuario dé su consentimiento de nuevo cuando inicie sesión posteriormente en la aplicación.

La solicitud de consentimiento para todo el inquilino requiere el consentimiento del administrador. El consentimiento del administrador concedido en nombre de una organización requiere los permisos estáticos registrados para la aplicación. Establezca esos permisos en el portal de registro de aplicaciones si necesita que un administrador dé su consentimiento en nombre de toda la organización.

Cuando la aplicación solicita permisos delegados que requieren el consentimiento del administrador, el usuario recibe un mensaje de error que indica que no está autorizado para dar su consentimiento a los permisos de la aplicación. El usuario debe solicitar a su administrador acceso a la aplicación. Si el administrador da el consentimiento para todo el inquilino, los usuarios de la organización no ven una página de consentimiento para la aplicación a menos que se revoquen los permisos concedidos anteriormente o que la aplicación solicite un nuevo permiso de forma incremental.

Los administradores que usan la misma aplicación verán el mensaje de consentimiento del administrador. El mensaje de consentimiento del administrador incluye una casilla que permite conceder a la aplicación acceso a los datos solicitados en nombre de los usuarios para todo el inquilino. Para obtener más información sobre la experiencia de consentimiento del usuario y del administrador, consulte Experiencia de consentimiento de la aplicación.

Algunos ejemplos de permisos delegados para Microsoft Graph que requieren consentimiento del administrador son:

  • La lectura de los perfiles completos de todos los usuarios con User.Read.All.
  • La escritura de datos en el directorio de una organización mediante Directory.ReadWrite.All.
  • La lectura de todos los grupos de seguridad del directorio de una organización mediante Groups.Read.All.

Para ver la lista completa de permisos de Microsoft Graph, consulte Referencia de permisos de Microsoft Graph.

También puede configurar permisos en sus propios recursos para requerir el consentimiento del administrador. Para obtener más información sobre cómo agregar ámbitos que requieren el consentimiento del administrador, consulte Incorporación de un ámbito que requiera el consentimiento del administrador.

Algunas organizaciones pueden cambiar la directiva de consentimiento del usuario predeterminada para el inquilino. Cuando la aplicación solicita acceso a los permisos, se evalúan con estas directivas. Es posible que el usuario tenga que solicitar el consentimiento del administrador incluso cuando no sea necesario de forma predeterminada. Para obtener información sobre cómo los administradores administran las directivas de consentimiento para las aplicaciones, consulte Administración de directivas de consentimiento de aplicaciones.

Nota:

En las solicitudes a los puntos de conexión de autorización, token o consentimiento para la Plataforma de identidad de Microsoft, si el identificador de recurso se omite en el parámetro de ámbito, se supone que el recurso es Microsoft Graph. Por ejemplo, scope=User.Read equivale a https://graph.microsoft.com/User.Read.

Los permisos de aplicación siempre requieren el consentimiento del administrador. Los permisos de aplicación no tienen un contexto de usuario y la concesión de consentimiento no se realiza en nombre de ningún usuario específico. En su lugar, a la aplicación cliente se le conceden permisos directamente, y estos tipos de permisos solo los usan los servicios de demonio y otras aplicaciones no interactivas que se ejecutan en segundo plano. Los administradores deben configurar los permisos por adelantado y conceder el consentimiento del administrador desde Centro de administración Microsoft Entra.

En caso de que la aplicación que solicita el permiso sea una aplicación multiinquilino, su registro de aplicación solo existe en el inquilino donde se creó, por lo que los permisos no se pueden configurar en el inquilino local. Si la aplicación solicita permisos que requieren el consentimiento del administrador, el administrador debe dar su consentimiento en nombre de los usuarios. Para dar su consentimiento a estos permisos, los administradores deben iniciar sesión en la propia aplicación, por lo que se desencadena la experiencia de inicio de sesión de consentimiento del administrador. Para obtener información sobre cómo configurar la experiencia de consentimiento del administrador para aplicaciones multiinquilino, consulte Habilitación de inicios de sesión multiinquilino.

Un administrador puede conceder el consentimiento para una aplicación con las siguientes opciones.

Normalmente, cuando se compila una aplicación que requiere el consentimiento del administrador, la aplicación necesita una página o una vista en la que el administrador pueda aprobar los permisos de la aplicación. Esta página puede ser:

  • parte del flujo de registro de la aplicación,
  • parte de la configuración de la aplicación o
  • un flujo de "conexión" dedicado.

En muchos casos, tiene sentido que la aplicación muestre la vista de "conexión" solo después de que un usuario haya iniciado sesión con una cuenta de Microsoft profesional o educativa.

Cuando inicia la sesión del usuario en la aplicación, puede identificar a la organización a la que pertenece el administrador antes de pedirle que apruebe los permisos necesarios. Aunque este paso no es estrictamente necesario, puede ayudarle a crear una experiencia más intuitiva para los usuarios de la organización.

Para iniciar la sesión del usuario, siga los tutoriales del protocolo de la Plataforma de identidad de Microsoft.

Solicitud de los permisos en el portal de registro de aplicaciones

En el portal de registro de aplicaciones, las aplicaciones pueden enumerar los permisos que necesitan, incluidos los permisos delegados y los permisos de aplicación. Esta configuración permite usar el ámbito .default y la opción Conceder consentimiento del administrador del Centro de administración Microsoft Entra.

En general, los permisos se deben definir estáticamente para una aplicación determinada. Deben formar un superconjunto de los permisos que la aplicación solicitará de manera dinámica o incremental.

Nota:

Los permisos de aplicación solo se pueden solicitar con .default. Por tanto, si la aplicación necesita permisos de aplicación, asegúrese de que se muestran en el portal de registro de aplicaciones.

Para configurar la lista de permisos solicitados estáticamente para una aplicación:

  1. Inicie sesión en el Centro de administración de Microsoft Entra como Administrador de aplicaciones en la nube.
  2. Vaya aIdentidad>Aplicaciones>Registros de aplicaciones>Todas las aplicaciones.
  3. Seleccione o cree una aplicación si aún no lo ha hecho.
  4. En la página Información general de la aplicación, en Administrar, seleccione Permisos de API>Agregar un permiso.
  5. Seleccione Microsoft Graph en la lista de API disponibles. A continuación, agregue los permisos que requiere la aplicación.
  6. Seleccione Agregar permisos.

Respuesta correcta

Si el administrador aprueba los permisos para la aplicación, la respuesta correcta tendrá un aspecto similar al siguiente:

GET http://localhost/myapp/permissions?tenant=aaaabbbb-0000-cccc-1111-dddd2222eeee&state=state=12345&admin_consent=True
Parámetro Descripción
tenant El inquilino del directorio que concedió los permisos solicitados, en formato GUID.
state Un valor incluido en la solicitud que también se devolverá en la respuesta del token. Puede ser una cadena de cualquier contenido que desee. El estado se usa para codificar información sobre el estado del usuario en la aplicación antes de que se haya producido la solicitud de autenticación, por ejemplo, la página o vista en la que estaban.
admin_consent Se establecerá en True.

Cuando haya recibido una respuesta correcta del punto de conexión de consentimiento del administrador, la aplicación habrá obtenido los permisos solicitados. Ahora puede solicitar un token para el recurso que desee.

Respuesta de error

Si el administrador no aprueba los permisos de la aplicación, la respuesta de error tendrá el aspecto siguiente:

GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request
Parámetro Descripción
error Una cadena de código de error que puede usarse para clasificar los tipos de errores que se producen. También se puede usar para reaccionar ante errores.
error_description Un mensaje de error específico que puede ayudar a un desarrollador a identificar la causa de un error.

Después de que el usuario da su consentimiento para los permisos de la aplicación, esta puede obtener tokens de acceso que representan los permisos de la aplicación para acceder a un recurso de alguna manera. Un token de acceso solo se puede usar para un único recurso. Sin embargo, dentro del token de acceso están todos los permisos codificados que se han concedido a la aplicación para ese recurso. Para adquirir un token de acceso, la aplicación puede realizar una solicitud al punto de conexión del token de la Plataforma de identidad de Microsoft, como esta:

POST common/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/json

{
    "grant_type": "authorization_code",
    "client_id": "00001111-aaaa-2222-bbbb-3333cccc4444",
    "scope": "https://microsoft.graph.com/Mail.Read https://microsoft.graph.com/mail.send",
    "code": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...",
    "redirect_uri": "https://localhost/myapp",
    "client_secret": "A1bC2dE3f..."  // NOTE: Only required for web apps
}

Puede usar el token de acceso resultante en las solicitudes HTTP al recurso. Dicho token indica al recurso de forma confiable que la aplicación tiene el permiso apropiado para realizar una tarea específica.

Para más información sobre el protocolo OAuth 2.0 y cómo obtener tokens de acceso, consulte la referencia del protocolo del punto de conexión de la Plataforma de identidad de Microsoft.

Consulte también