Información sobre los permisos y el consentimiento

  • 3 minutos

Las aplicaciones que se integran en la plataforma de identidad de Microsoft siguen un modelo de autorización que permite a los usuarios y los administradores controlar el modo en que se puede acceder a los datos.

La plataforma de identidad de Microsoft implementa el protocolo de autorización OAuth 2.0. OAuth 2.0 es un método a través del cual una aplicación de terceros puede acceder a recursos hospedados en Web en nombre de un usuario. Cualquier recurso hospedado en Web que se integre con la Plataforma de identidad de Microsoft tiene un identificador de recursos o un URI de identificador de aplicación.

Estos son algunos ejemplos de recursos hospedados en Web de Microsoft:

  • Microsoft Graph: https://graph.microsoft.com
  • Mail API de Microsoft 365: https://outlook.office.com
  • https://vault.azure.netAzure Key Vault:

Ocurre lo mismo con cualquier recurso de terceros integrado en la plataforma de identidad de Microsoft. Cualquiera de estos recursos también puede definir un conjunto de permisos que se puede usar para dividir la funcionalidad de ese recurso en fragmentos menores. Al fragmentar la funcionalidad de un recurso en conjuntos de permisos pequeños, se pueden crear aplicaciones de terceros para solicitar solo los permisos que necesitan para realizar sus tareas. Los usuarios y administradores pueden saber a qué datos puede acceder la aplicación.

En OAuth 2.0, estos tipos de conjuntos de permisos se denominan ámbitos. A menudo se hace referencia a ellos como permisos. En la Plataforma de identidad de Microsoft, un permiso se representa como un valor de cadena. Una aplicación solicita los permisos que necesita al especificar el permiso en el parámetro de consulta scope. La plataforma de identidad admite varios ámbitos de OpenID Connect bien definidos, y permisos basados en recursos (cada permiso se indica al anexar el valor de permiso al identificador del recurso o al URI del identificador de aplicación). Por ejemplo, la cadena de permiso https://graph.microsoft.com/Calendars.Read se usa para solicitar permiso para leer los calendarios de los usuarios en Microsoft Graph.

Una aplicación suele solicitar estos permisos, para lo que especifica los ámbitos en las solicitudes al punto de conexión de la autorización de la Plataforma de identidad de Microsoft. Sin embargo, algunos permisos con privilegios elevados solo se pueden conceder con el consentimiento del administrador. Se pueden solicitar o conceder con el punto de conexión de consentimiento del administrador.

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 es equivalente a https://graph.microsoft.com/User.Read.

Tipos de permisos

La Plataforma de identidad de Microsoft admite dos tipos de permisos: permisos delegados y acceso exclusivo de aplicación.

  • Permisos delegados: se utilizan en aplicaciones que tienen un usuario con la sesión iniciada. Para estas aplicaciones, el usuario o un administrador dan su consentimiento para los permisos que la aplicación requiere. A la aplicación se le delega el permiso para actuar como el usuario que inició sesión al realizar llamadas al recurso de destino.

  • Los permisos de acceso exclusivo de aplicación los usan las aplicaciones que se ejecutan sin la presencia de un usuario con la sesión iniciada; por ejemplo, las aplicaciones que se ejecutan como demonios o servicios en segundo plano. Solo un administrador puede dar su consentimiento para los permisos de acceso exclusivo de aplicación.

Las aplicaciones de la Plataforma de identidad de Microsoft dependen del consentimiento para poder acceder a los recursos o las API necesarios. Hay una serie de tipos de consentimiento que la aplicación puede necesitar saber para que se pueda ejecutar correctamente. Si va a definir permisos, también debe saber cómo accederán los usuarios a la aplicación o la API.

Hay tres tipos de consentimiento: consentimiento del usuario estático, consentimiento del usuario incremental y dinámico y consentimiento del administrador.

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 Azure Portal. 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 los permisos estáticos de la aplicación definidos en Azure Portal mantenían un código ordenado y sencillo, presenta algunos problemas para los desarrolladores:

  • Una aplicación tiene que solicitar todos los permisos que podría necesitar alguna vez tras el primer inicio de sesión del usuario. Esto puede originar una lista larga de permisos, lo que desanimaría a los usuarios finales de aprobar el acceso de la aplicación en el inicio de sesión inicial.

  • La aplicación tiene que conocer por adelantado todos los recursos a los que va a tener acceso alguna vez. Es difícil crear aplicaciones que puedan acceder a un número arbitrario de recursos.

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 Azure Portal y, en su lugar, 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 use características de aplicación adicionales.

Para ello, puede especificar los ámbitos que la aplicación necesita en cualquier momento incluyendo los nuevos ámbitos en el parámetro scope al solicitar 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 acceso exclusivo de aplicación.

Importante

El consentimiento dinámico puede resultar conveniente, pero presenta un gran desafío para los permisos que requieren el consentimiento del administrador, ya que la experiencia de consentimiento de administrador no conoce los permisos en el momento del consentimiento. Si necesita permisos con privilegios de administrador o si su aplicación usa el consentimiento dinámico, debe registrar todos los permisos en Azure Portal (no solo el subconjunto de permisos que requieren el consentimiento del administrador). Esto permite a los administradores de inquilinos dar su consentimiento en nombre de todos los usuarios.

Se requiere el consentimiento del administrador si la aplicación necesita acceder a determinados permisos con privilegios elevados. El consentimiento del administrador garantiza que los administradores disponen de algunos controles adicionales antes de autorizar a las aplicaciones o a los usuarios el acceso a datos con privilegios elevados de la organización.

El consentimiento del administrador concedido en nombre de una organización todavía requiere los permisos estáticos registrados para la aplicación. Establezca esos permisos para las aplicaciones en el portal de registro de aplicaciones si necesita que un administrador dé su consentimiento en nombre de toda la organización. Esto reduce los ciclos que el administrador de la organización necesita para instalar la aplicación.

En una solicitud de autorización de OpenID Connect u OAuth 2.0, una aplicación puede solicitar los permisos que necesita mediante el parámetro de consulta del ámbito. Por ejemplo, cuando un usuario inicia sesión en una aplicación, la aplicación envía una solicitud como la del ejemplo siguiente. Los saltos de línea se han agregado por cuestiones de legibilidad.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&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.