Escenarios de MSAL.NET

Introduction

Las bibliotecas de autenticación de .NET admiten escenarios relacionados con la protección de una API web y la adquisición de tokens para una API web protegida. MSAL.NET solo se usa para este último.

Como desarrollador, puede adquirir un token de varios tipos de aplicación, incluidas aplicaciones web, aplicaciones móviles, aplicaciones de escritorio, API web y aplicaciones que se ejecutan en dispositivos que no tienen un explorador (o iOT). Estos tipos de aplicaciones se separan en dos categorías:

• Las aplicaciones cliente públicas (de escritorio y móviles) usan la PublicClientApplication clase
• Aplicaciones cliente confidenciales (aplicaciones web, API web y aplicaciones de demonio: escritorio o web). Este tipo de aplicaciones usan .ConfidentialClientApplication

MSAL.NET admite la adquisición de tokens en el nombre de un icono de usuario de o, (y solo para aplicaciones cliente confidenciales), en el nombre de la propia aplicación (para ningún usuario). En ese caso, la aplicación cliente confidencial comparte un secreto con Microsoft Entra ID

MSAL.NET admite varias plataformas (.NET Framework, .NET y .NET MAUI). .NET aplicaciones también se pueden ejecutar en diferentes sistemas operativos (Windows, Linux y macOS). Los escenarios pueden ser diferentes en función de las plataformas.

Escenarios

En la imagen siguiente se resumen los escenarios admitidos y se muestran en qué plataforma y a qué protocolo Microsoft Entra corresponde:

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

Para proteger una aplicación web (iniciando sesión en el usuario), usará ASP.NET o ASP.NET Core con el middleware de OpenID Connect de ASP.NET. Esto implica validar el token que realizan las extensiones identityModel para .NET biblioteca, no MSAL.NET.

Para llamar a la API web en el nombre del usuario, usará MSAL.NET ConfidentialClientApplication, aprovechando el flujo de código de autorización y, a continuación, almacenar el token adquirido en la caché de tokens y adquirir un token de forma silenciosa desde la memoria caché cuando sea necesario. MSAL actualizará el token si es necesario.

Aplicación móvil que llama a una API web en nombre del usuario que ha iniciado sesión de forma interactiva

Para llamar a una API web desde una aplicación móvil, use los métodos de adquisición de tokens interactivos de PublicClientApplication de MSAL.NET. Estos métodos interactivos permiten controlar la experiencia de la interfaz de usuario de inicio de sesión, así como la ubicación del cuadro de diálogo interactivo en algunas plataformas.

Para habilitar esta interacción, MSAL.NET aprovecha un explorador web. Hay especificidades en función de la plataforma móvil. En iOS y Android, puede elegir si desea aprovechar el explorador del sistema (el valor predeterminado) o un explorador web incrustado. Puede habilitar el uso compartido de caché de tokens en iOS.

Protección de la propia aplicación con Intune

La aplicación móvil (escrita en Xamarin.iOS o Xamarin. Android) puede tener aplicadas directivas de protección de aplicaciones, de modo que InTune pueda administrarla y reconocerla como una aplicación administrada. El SDK de InTune es independiente de MSAL y se comunica con Microsoft Entra ID por su cuenta.

Aplicación de demonio de escritorio o servicio que llama a una API web como sí misma (en su propio nombre)

Puede escribir una aplicación de demonio que adquiera un token mediante su propia identidad en la parte superior mediante los métodos de adquisición de credenciales de cliente de ConfidentialClientApplication de MSAL.NET. Estos suponen que la aplicación ha registrado previamente un secreto (contraseña de aplicación o certificado) con Microsoft Entra ID, que luego comparte con esta llamada.

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

Las aplicaciones de escritorio pueden usar la misma autenticación interactiva que las aplicaciones móviles.

Para Windows aplicaciones hospedadas, también es posible que las aplicaciones que se ejecutan en equipos unidos a un dominio de Windows o Microsoft Entra se unan para adquirir un token de forma silenciosa mediante la autenticación integrada de Windows.

Si la aplicación de escritorio es una aplicación .NET Core que se ejecuta en Linux o Mac, no puede usar el flujo de autenticación interactiva (ya que .NET Core no proporciona un explorador web) ni la autenticación integrada Windows. La mejor opción en ese caso es usar el flujo de código del dispositivo, como se explica en Aplicación sin un explorador o aplicación iOT que llama a una API en el nombre del usuario.

Aunque no se recomienda, puede usar el flujo de nombre de usuario y contraseña en aplicaciones cliente públicas; Todavía es necesario en algunos escenarios (como DevOps), pero tenga en cuenta que su uso impone restricciones en la aplicación. Por ejemplo, no puede iniciar sesión a los usuarios que necesiten realizar Multi Factor Authentication (acceso condicional) ni aprovechar las ventajas del inicio de sesión único (SSO). 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 heredados.

En las aplicaciones de escritorio, si quiere que la caché de tokens sea persistente, debe personalizar la serialización de caché de tokens.

Aplicación sin explorador o aplicación iOT que llama a una API en el nombre del usuario

Las aplicaciones que se ejecutan en un dispositivo sin un explorador seguirán siendo capaces de llamar a una API en el nombre de un usuario, después de que el usuario inicie sesión en otro dispositivo que tenga un explorador web. Para ello, deberá usar el flujo de código de dispositivo.

API web que llama a otra API web de bajada en el nombre del usuario para el que se llamó

Si desea que el ASP.NET o ASP.NET Core API web protegida llame a otra API web en nombre del usuario representado por el token de acceso se usó para llamar a la API, deberá:

• Valide el token. Para ello, usará el middleware JWT de ASP.NET en segundo plano. Esto también implica validar el token que realizan las extensiones identityModel para .NET biblioteca, no MSAL.NET
• A continuación, deberá adquirir un token para la API web de bajada mediante el método de ConfidentialClientApplication Adquirir un token en nombre de un usuario en llamadas de servicio a servicio.
• Las API web que llaman a otra API web también tendrán que proporcionar una serialización de caché personalizada.

API web que llama a otra API en su propio nombre

Al igual que en las aplicaciones de demonio de escritorio o servicio, una API web de demonio (o una aplicación web de demonio) puede usar los métodos de adquisición de credenciales de cliente de ConfidentialClientApplication de MSAL.NET.

Características transversales

En todos los escenarios que quiera:

• Solución de problemas mediante la activación de registros o telemetría
• Comprender cómo reaccionar a las excepciones debido al servicio MsalServiceExceptionMicrosoft Entra o a algo incorrecto que sucede en el propio cliente.MsalClientException
• Uso de MSAL.NET con un proxy