Desarrollo de aplicaciones de Microsoft Entra

  • 3 minutos

Ahora que conoce mejor los principios básicos y las ventajas de Microsoft Entra ID, debe determinar cómo puede usar sus funcionalidades para implementar la autenticación y autorización para la aplicación. Es consciente de que, para ayudar a proteger los datos de los clientes, debe asegurarse de que su implementación se integrará con los mecanismos de control de acceso de PostgreSQL. Ha decidido empezar por identificar las tareas que intervienen en el desarrollo, el aprovisionamiento y la administración de las aplicaciones de Microsoft Entra. También quiere determinar cómo puede abordar la necesidad de proporcionar acceso a la aplicación a varios clientes.

Para implementar aplicaciones basadas en Microsoft Entra ID, deberá realizar varias tareas de administración relacionadas con la aplicación, incluidos el registro, la configuración de sus permisos y la administración de sus secretos.

¿Qué es el registro de aplicaciones?

Al trabajar en un entorno de Microsoft Entra, un usuario se autentica en una aplicación en dos fases:

  1. En primer lugar, Microsoft Entra ID comprueba la identidad del usuario. Tras una autenticación correcta, Microsoft Entra ID emite tokens que contienen información que refleja la autenticación correcta.
  2. El usuario pasa los tokens a la aplicación. La aplicación valida el token de seguridad del usuario para garantizar que la autenticación se ha realizado correctamente.

Para realizar dicha validación, la aplicación debe ser capaz de comunicarse de forma segura con Microsoft Entra ID. Esto, a su vez, requiere que la propia aplicación funcione como una entidad de seguridad de Microsoft Entra. Para que sea posible, debe asegurarse de que la aplicación se representa de alguna forma en el mismo inquilino de Microsoft Entra que contiene la cuenta del usuario autenticador.

Hay dos representaciones de una aplicación en Microsoft Entra ID:

  • Un objeto de aplicación, que define las propiedades de la aplicación.
  • Una entidad de servicio, que proporciona la funcionalidad de autenticación y autorización y hace referencia al objeto de aplicación.

Puede crear objetos de aplicación directamente en Azure Portal desde la hoja Registros de aplicaciones. Para sus propias aplicaciones personalizadas, este registro crea automáticamente la entidad de servicio correspondiente. Después, puede administrar entidades de servicio en Azure Portal desde la hoja Aplicaciones empresariales.

Durante el registro de la aplicación, tiene la opción de especificar el identificador uniforme de recursos (URI) de redirección de la aplicación. Su valor designa la ubicación a la que el servidor de autorización redirige al usuario después de que la aplicación se haya autorizado correctamente. El servidor de autorización envía el código o el token al identificador URI de redirección, por lo que es importante que registre la ubicación correcta como parte del proceso de registro de la aplicación.

Nota:

El URI de redirección debe comenzar por https, a menos que haga referencia a localhost, en cuyo caso, puede usar http://localhost. También distingue mayúsculas de minúsculas.

¿Qué son los permisos de aplicaciones?

Las aplicaciones que se integran con Microsoft Entra ID siguen un modelo de autorización que le permite controlar de forma granular sus permisos para otras aplicaciones y recursos integrados en Microsoft Entra. Microsoft Entra ID se basa en el modelo de autorización de OAuth 2.0 para implementar estos permisos. En OAuth 2.0, los permisos se organizan en conjuntos, normalmente denominados ámbitos.

Como desarrollador, puede solicitar los permisos que necesita la aplicación especificando una cadena de permiso como parte de su configuración. Por ejemplo, al establecer la cadena de permiso en "https://graph.microsoft.com/Calendars.Read", indica que la aplicación necesitará tener la capacidad de leer los calendarios de los usuarios en Microsoft Graph. A la aplicación se le deben conceder estos permisos mediante un consentimiento, que debe conceder un usuario o administrador de Microsoft Entra, en función del alcance de estos permisos.

Microsoft Entra ID admite dos tipos de permisos:

  • Los permisos delegados los utilizan las aplicaciones interactivas que tienen un usuario con la sesión iniciada. Como resultado, la aplicación actúa en nombre de un usuario que ha iniciado sesión cuando accede al recurso de destino.
  • Los permisos de aplicación los usan las aplicaciones que se ejecutan sin depender de un usuario con la sesión iniciada; por ejemplo, los servicios en segundo plano. Estas aplicaciones requieren consentimiento administrativo.

¿Qué son los secretos de las aplicaciones?

Hay dos tipos de autenticación disponibles para las entidades de servicio:

  • Autenticación basada en contraseñas, que usa los secretos de aplicación que se pueden generar directamente en Azure Portal. Al generar un secreto, se especifica su duración.
  • Autenticación basada en certificados, que usa los certificados que se cargan en Microsoft Entra ID.

Nota:

Si la aplicación se hospeda en un recurso de proceso de Azure, como una máquina virtual (VM) de Azure, una aplicación web de Azure App Service o un clúster de AKS, en lugar de usar entidades de servicio, es preferible usar identidades administradas para la identidad de la aplicación. Esto elimina la necesidad de administrar contraseñas o certificados para la autenticación.

¿Cuáles son los distintos tipos de escenarios de autenticación de aplicaciones?

El flujo de autenticación y los detalles de configuración correspondientes dependen del tipo de aplicación. Las categorías comunes de tipos de aplicación incluyen:

  • Aplicaciones basadas en explorador. Son aplicaciones web en las que los tokens son adquiridos por una aplicación de JavaScript o TypeScript que se ejecuta en el explorador. Estas aplicaciones suelen usar un marco como Angular, React o Vue. MSAL.js es la única biblioteca de autenticación de Microsoft que admite SPA.
  • Aplicaciones cliente públicas. Se trata de aplicaciones que siempre dependen de los usuarios que han iniciado sesión para obtener tokens. Estas aplicaciones incluyen aplicaciones de escritorio y móviles que llaman a las API web en nombre de los usuarios que han iniciado sesión.
  • Aplicaciones cliente confidenciales. Obtienen tokens de forma autónoma. Las aplicaciones de esta categoría incluyen aplicaciones web que llaman a una API web, API web que llaman a otra API web, demonios de Linux y servicios de Windows.

Los dos primeros elementos anteriores autentican a un usuario, mientras que el tercero solo autentica una aplicación o un servicio entre el usuario y un servicio back-end. En este caso, el servicio back-end no sabrá nada sobre el usuario final, pero sabrá qué aplicación lo usa. Por ejemplo, piense en una aplicación que usa Azure Maps como un servicio back-end. El servicio Maps debe saber que una aplicación autorizada lo llama para una facturación correcta, pero no necesita saber nada sobre el usuario final.

¿Cuál es la diferencia entre las aplicaciones de Microsoft Entra de un solo inquilino y multiinquilino?

Como desarrollador, puede optar por configurar la aplicación para que sea de un solo inquilino o multiinquilino durante el registro de la aplicación:

  • Las aplicaciones de un solo inquilino están disponibles en el inquilino en el que se han registrado, que también se conoce como su inquilino principal.
  • Las aplicaciones multiinquilino están disponibles para los usuarios en su inquilino principal y en otros inquilinos de Microsoft Entra.

Si usa Azure Portal para el registro de la aplicación, especifique el inquilino de la aplicación estableciendo su propiedad audience en uno de los valores siguientes:

  • Solo las cuentas de este directorio. Esto da como resultado la configuración de un solo inquilino. De hecho, esto le permite conceder acceso a la aplicación a cualquier entidad de seguridad del inquilino, incluidas las cuentas de invitado.
  • Cuentas en cualquier directorio de Microsoft Entra. Esto da como resultado la configuración multiinquilino. Esto permite a los usuarios fuera de su organización registrar la aplicación en sus respectivos inquilinos de Microsoft Entra.
  • Las cuentas de cualquier directorio de Microsoft Entra y las cuentas personales de Microsoft (por ejemplo, las de Skype, Xbox y Outlook.com). Esto también da como resultado una configuración multiinquilino, pero permite que los usuarios con cuentas personales de Microsoft usen la aplicación.

Nota:

Un objeto de aplicación solo existe en el inquilino principal, pero en el caso de la configuración multiinquilino, varias entidades de servicio pueden hacer referencia a él en inquilinos de Microsoft Entra diferentes.