Tipos de aplicaciones y flujos de autenticación de la plataforma de identidad de Microsoft

Artículo
03/20/2024

La Plataforma de identidad de Microsoft admite la autenticación para diferentes tipos de arquitecturas de aplicación modernas. Todas ellas se basan en los protocolos estándar del sector OAuth 2.0 y OpenID Connect. Con las bibliotecas de autenticación de la plataforma de identidad de Microsoft, las aplicaciones autentican las identidades y adquieren tokens para acceder a API protegidas.

En este artículo se describen los flujos de autenticación y los escenarios de aplicaciones en los que se usan.

Categorías de aplicaciones

Los tokens de seguridad se pueden adquirir a partir de varios tipos de aplicaciones, entre las que se incluyen:

Aplicaciones web
Aplicaciones móviles
Aplicaciones de escritorio
API web

Los tokens también pueden ser adquiridos por aplicaciones que se ejecutan en dispositivos sin explorador o en Internet de las cosas (IoT).

En las secciones siguientes se describen las categorías de aplicaciones.

Recursos protegidos frente a aplicaciones cliente

Los escenarios de autenticación implican dos actividades:

Adquisición de tokens de seguridad para una API web protegida: Se recomienda usar la biblioteca de autenticación de Microsoft (MSAL), desarrollada por Microsoft y con el soporte técnico de Microsoft.
Protección de una API web o una aplicación web: un reto a la hora de proteger estos recursos es validar el token de seguridad. En algunas plataformas, Microsoft ofrece bibliotecas de middleware.

Con usuarios o sin usuarios

La mayoría de los escenarios de autenticación adquieren tokens en nombre de un usuario con la sesión iniciada.

Escenarios con usuarios

Sin embargo, también hay aplicaciones de demonio. En estos escenarios, las aplicaciones adquieren los tokens en su propio nombre, sin usuario.

Escenarios con aplicaciones de demonio

Aplicaciones cliente públicas y confidenciales, de página única

Hay varios tipos de aplicaciones que pueden adquirir tokens de seguridad. Estas aplicaciones tienden a dividirse en las tres categorías siguientes. Cada se usa con diferentes bibliotecas y objetos.

Aplicaciones de página única: también conocidas como SPA, son aplicaciones web en las que los tokens son adquiridos por una aplicación de JavaScript o TypeScript que se ejecuta en el explorador. Muchas aplicaciones modernas tienen una aplicación de página única en el front-end, que está escrita principalmente en JavaScript. A menudo, la aplicación usa un marco como Angular, React o Vue. MSAL.js es la única biblioteca de autenticación de Microsoft que admite aplicaciones de página única.
Aplicaciones cliente públicas: las aplicaciones de esta categoría, como los tipos siguientes, siempre inician la sesión de los usuarios:
- Aplicaciones de escritorio que llaman a API web en nombre de los usuarios que han iniciado sesión
- Aplicaciones móviles
- Aplicaciones que se ejecutan en dispositivos sin explorador, como las que se ejecutan en IoT
Aplicaciones cliente confidenciales: las aplicaciones de esta categoría incluyen:
- Aplicaciones web que llaman a una API web
- API web que llaman a una API web
- Aplicaciones de demonio, incluso cuando se implementan como servicio de consola, como un demonio de Linux o un servicio de Windows

los flujos de autenticación disponibles difieren en función de la audiencia de inicio de sesión. Algunos flujos solo están disponibles para las cuentas profesionales o educativas. Otros están disponibles para las cuentas profesionales o educativas y para las cuentas Microsoft personales.

Para más información, consulte Tipos de cuenta admitidos.

Tipos de aplicación

La Plataforma de identidad de Microsoft admite la autenticación en estas arquitecturas de aplicaciones:

Aplicaciones de una sola página
Aplicaciones web
API web
Aplicaciones móviles
Aplicaciones nativas
Aplicaciones de demonio
Aplicaciones de servidor

Las aplicaciones usan los distintos flujos de autenticación para iniciar la sesión de los usuarios y obtener tokens para llamar a API protegidas.

Aplicación de una sola página

Muchas aplicaciones web modernas se compilan como aplicaciones de página única del lado cliente. Estas aplicaciones usan JavaScript o un marco de trabajo como Angular, Vue y React. Estas aplicaciones se ejecutan en un explorador web.

Las aplicaciones de página única difieren de las aplicaciones web tradicionales del lado servidor en las características de autenticación. Con la plataforma de identidad de Microsoft las aplicaciones de página única pueden iniciar la sesión de los usuarios y obtengan tokens para acceder a los servicios de back-end o a las API web. La Plataforma de identidad de Microsoft ofrece dos tipos de concesión para las aplicaciones JavaScript:

MSAL.js (2.x)	MSAL.js (1.x)

Aplicación web que inicia la sesión de un usuario

Para ayudar a proteger una aplicación web que inicia la sesión de un usuario:

Si se está desarrollando en .NET, se usa ASP.NET o ASP.NET Core con el middleware ASP.NET OpenID Connect. La protección de un recurso conlleva la validación del token de seguridad, que se realiza con las extensiones de IdentityModel para .NET y no con las bibliotecas MSAL.
Si se desarrolla en Node.js, se usa Nodo MSAL.

Para más información, consulte Aplicación web que permite iniciar sesión a los usuarios.

Aplicación web que inicia la sesión de un usuario y llama a una API web en nombre del usuario

Aplicaciones web que llama a API web

Para llamar a una API web desde una aplicación web en nombre de un usuario, use el flujo de código de autorización y almacene los tokens adquiridos en la caché de tokens. Cuando sea necesario, MSAL actualiza los tokens y el controlador adquiere los tokens de la memoria caché de forma silenciosa.

Para más información, consulte Aplicación web que llama a las API web.

Aplicación de escritorio que llama a una API web en nombre de un usuario que ha iniciado sesión

Para que una aplicación de escritorio llame a una API web que inicia la sesión de los usuarios, use los métodos de adquisición de tokens interactivos de MSAL. Estos métodos interactivos permiten controlar la experiencia de inicio de sesión en la interfaz de usuario. MSAL usa un explorador web para esta interacción.

Aplicación de escritorio que llama a una API web

Existe otra posibilidad para las aplicaciones alojadas en Windows en ordenadores unidos a un dominio de Windows o mediante Microsoft Entra ID. Estas aplicaciones pueden adquirir un token de forma silenciosa con la autenticación integrada de Windows.

Las aplicaciones que se ejecutan en un dispositivo sin explorador podrán seguir llamando a una API en nombre de un usuario. Para realizar la autenticación, el usuario debe iniciar sesión en otro dispositivo que tenga un explorador web. En este escenario es necesario usar el flujo de código del dispositivo.

Flujo de código de dispositivo

Aunque no se recomienda usarlo, el flujo de nombre de usuario y contraseña está disponible en las aplicaciones cliente públicas. Este flujo sigue siendo necesario en algunos escenarios, como DevOps.

El uso del flujo de nombre de usuario y contraseña restringe las aplicaciones. Por ejemplo, las aplicaciones no pueden dar de alta a un usuario que necesite utilizar la autenticación multifactor o la herramienta de acceso condicional de Microsoft Entra ID. Las aplicaciones tampoco se benefician del inicio de sesión único. La autenticación mediante el flujo de nombre de usuario y contraseña va en contra de los principios de la autenticación moderna y solo se proporciona por motivos de herencia.

En aplicaciones de escritorio, si quiere que la caché de tokens persista, puede personalizar la serialización de la caché de tokens. Con la implementación de la serialización de la caché de tokens dual, puede usar cachés de tokens compatibles con versiones anteriores y posteriores.

Para más información, consulte Aplicación de escritorio que llama a las API web.

Aplicación móvil que llama a una API web en nombre de un usuario interactivo

De forma parecida a una aplicación de escritorio, una aplicación móvil llama a los métodos interactivos de adquisición de tokens de MSAL para adquirir un token para llamar a una API web.

Aplicación móvil que llama a una API web

MSAL iOS y MSAL Android usan el explorador web del sistema de forma predeterminada. Pero puede dirigirlos para que usen la vista web insertada en su lugar. Existen algunas características específicas que dependen de la plataforma móvil: Plataforma universal de Windows (UWP), iOS o Android.

Algunos escenarios, como los que implican el acceso condicional relacionado con un identificador de dispositivo o una inscripción de dispositivo, requieren que se instale un agente en el dispositivo. Algunos ejemplos de agentes son Portal de empresa de Microsoft en Android y Microsoft Authenticator en Android e iOS.

Para más información, consulte Aplicación móvil que llama a las API web.

Nota:

Una aplicación móvil que usa MSAL iOS o MSAL Android puede tener aplicadas directivas de protección de aplicaciones. Por ejemplo, las directivas pueden impedir que un usuario copie texto protegido. Intune administra la aplicación móvil y reconoce este servicio como una aplicación administrada. Para más información, consulte Introducción al SDK para aplicaciones de Microsoft Intune.

Intune App SDK es independiente de las bibliotecas MSAL e interactúa con Microsoft Entra ID por sí solo.

API web protegida

Puede usar el punto de conexión de la Plataforma de identidad de Microsoft para proteger servicios web como la API RESTful de la aplicación. Se llama a una API web protegida mediante un token de acceso. El token ayuda a proteger los datos de la API y a autenticar las solicitudes entrantes. El llamador de una API web anexa un token de acceso al encabezado de autorización de una solicitud HTTP.

Si quiere proteger su API web de ASP.NET o ASP.NET Core, valide el token de acceso. Para la validación se usa el middleware JWT de ASP.NET. Esta validación se realiza con la biblioteca de extensiones IdentityModel para .NET, no con MSAL.NET.

Para más información, consulte API web protegida.

API web que llama a otra API web en nombre de un usuario

Para que la API web protegida llame a otra API web en nombre de un usuario, la aplicación debe adquirir un token para la API web de bajada. Estas llamadas a veces se denominan llamadas de servicio a servicio. Las API web que llaman a otras API web tienen que proporcionar serialización de caché personalizada.

API web que llama a otra API web

Para más información, consulte API web que llama a las API web.

Aplicación de demonio que llama a una API web en nombre del demonio

Las aplicaciones que contienen procesos de larga duración o que funcionan sin la interacción de usuario también necesitan un modo de acceder a API web protegidas. Estas aplicaciones pueden autenticarse y obtener tokens mediante la identidad de la aplicación. La aplicación demuestra su identidad mediante un certificado o secreto de cliente.

Puede escribir estas aplicaciones de demonio que adquieren un token para la aplicación que realiza la llamada con los métodos de adquisición de credenciales de cliente de MSAL. Estos métodos requieren un secreto de cliente que se agrega al registro de la aplicación en Microsoft Entra ID. A continuación, la aplicación comparte el secreto con el demonio al que ha llamado. Ejemplos de estos secretos son las contraseñas de aplicación, la aserción de certificado y la aserción de cliente.

Aplicación de demonio a la que llaman otras aplicaciones y API

Para más información, consulte Aplicación de demonio que llama a las API web.

Escenarios y flujos de autenticación compatibles

Puede usar flujos de autenticación para implementar los escenarios de aplicaciones que solicitan tokens. No hay ninguna asignación individual entre los escenarios de aplicaciones y los flujos de autenticación.

Los escenarios que implican la adquisición de tokens también se asignan a flujos de autenticación de OAuth 2.0. Para más información, consulte Protocolos OAuth 2.0 y OpenID Connect en la Plataforma de identidad de Microsoft.

Tutorial detallado de escenarios	Flujo y concesión de OAuth 2.0	Público
Aplicación de una sola página	Código de autorización con PKCE	Cuentas profesionales o educativas, cuentas personales y Azure Active Directory B2C (Azure AD B2C)
Aplicación de una sola página	Implícito	Cuentas profesionales o educativas, cuentas personales y Azure Active Directory B2C (Azure AD B2C)
Aplicación web que permite iniciar sesión a los usuarios	Código de autorización	Cuentas profesionales o educativas, cuentas personales y Azure AD B2C
Aplicación web que llama a las API web	Código de autorización	Cuentas profesionales o educativas, cuentas personales y Azure AD B2C
Aplicación de escritorio que llama a las API web	De forma interactiva mediante un código de autorización con PKCE	Cuentas profesionales o educativas, cuentas personales y Azure AD B2C
	Autenticación integrada de Windows	Cuentas profesionales o educativas
	Contraseña del propietario del recurso	Cuentas profesionales o educativas y Azure AD B2C
Aplicación sin explorador	Código del dispositivo	Cuentas profesionales o educativas, cuentas personales, pero no Azure AD B2C
Aplicación móvil que llama a las API web	De forma interactiva mediante un código de autorización con PKCE	Cuentas profesionales o educativas, cuentas personales y Azure AD B2C
	Contraseña del propietario del recurso	Cuentas profesionales o educativas y Azure AD B2C
Aplicación de demonio que llama a las API web	Credenciales de cliente	Permisos solo para aplicaciones que no tienen usuario y solo se utilizan en organizaciones Microsoft Entra
API web que llama a API web	En nombre de	Cuentas profesionales o educativas y cuentas personales

Escenarios, plataformas y lenguajes compatibles

Las bibliotecas de autenticación de Microsoft admiten varias plataformas:

.NET
.NET Framework
Java
JavaScript
macOS
Android nativo
iOS nativo
Node.js
Python
Windows 10/UWP

También puede usar varios lenguajes para compilar las aplicaciones.

En la columna Windows de la tabla siguiente, cada vez que se menciona .NET, también es posible .NET Framework. El último se omite para evitar la acumulación en la tabla.

Escenario	Windows	Linux	Mac	iOS	Android
Aplicación de una sola página	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Aplicación de una sola página	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Aplicación web que permite iniciar sesión a los usuarios	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node
Aplicación web que llama a las API web	ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node
Aplicación de escritorio que llama a las API web	MSAL.NET Java de MSAL MSAL Python MSAL Node	MSAL.NET Java de MSAL MSAL Python MSAL Node	MSAL.NET Java de MSAL MSAL Python MSAL Node MSAL.objc
Aplicación móvil que llama a las API web	MSAL.NET MSAL.NET			MSAL.objc	MSAL.Android
Aplicación de demonio	MSAL.NET Java de MSAL MSAL Python MSAL Node	MSAL.NET Java de MSAL MSAL Python MSAL Node	MSAL.NET Java de MSAL MSAL Python MSAL Node
API web que llama a API web	ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node	ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node	ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node