Cenários de MSAL.NET

Introdução

As bibliotecas de autenticação .NET dão suporte a cenários que envolvem a proteção de uma API Web e a aquisição de tokens para uma API Web protegida. MSAL.NET é usado apenas para este último.

Como desenvolvedor, você pode adquirir um token de vários tipos de aplicativo, incluindo aplicativos Web, aplicativos móveis, aplicativos da área de trabalho, APIs Web e aplicativos em execução em dispositivos que não têm um navegador (ou iOT). Esses tipos de aplicativos são separados em duas categorias:

• Aplicativos cliente públicos (desktop e móvel) usam a PublicClientApplication classe
• Aplicativos cliente confidenciais (aplicativos Web, APIs Web e aplicativos daemon – desktop ou Web). Esses tipos de aplicativos usam o ConfidentialClientApplication.

MSAL.NET dá suporte à aquisição de tokens no nome de um de usuário ou (e somente para aplicativos cliente confidenciais), no nome do próprio aplicativo (para nenhum usuário). Nesse caso, o aplicativo cliente confidencial compartilha um segredo com Microsoft Entra ID

MSAL.NET dá suporte a várias plataformas (.NET Framework, .NET e .NET MAUI). .NET aplicativos também podem ser executados em sistemas operacionais diferentes (Windows, Linux e macOS). Os cenários podem ser diferentes dependendo das plataformas.

Os cenários

A imagem a seguir resume os cenários com suporte e mostra em qual plataforma e para qual protocolo Microsoft Entra isso corresponde:

Aplicativo Web que entra em usuários e chama uma API Web em nome do usuário

Para proteger um aplicativo Web (entrar no usuário), você usará ASP.NET ou ASP.NET Core com o middleware ASP.NET OpenID Connect. Isso envolve validar o token que é feito pelas extensões IdentityModel para .NET biblioteca, não MSAL.NET.

Para chamar a API Web no nome do usuário, você usará MSAL.NETConfidentialClientApplication, aproveitando o fluxo de código de autorização e, em seguida, armazenando o token adquirido no cache de token e adquirindo um token silenciosamente do cache quando necessário. A MSAL atualiza o token, se necessário.

Aplicativo móvel que chama uma API Web em nome do usuário que está conectado interativamente

Para chamar uma API Web de um aplicativo móvel, use os métodos interativos de aquisição de token do PublicClientApplication da MSAL.NET. Esses métodos interativos permitem controlar a experiência de interface do usuário de entrada, bem como o local da caixa de diálogo interativa em algumas plataformas.

Para habilitar essa interação, MSAL.NET aproveita um navegador da Web. Há especificidades dependendo da plataforma móvel. No iOS e no Android, você pode escolher se deseja aproveitar o navegador do sistema (o padrão) ou um navegador da Web inserido. Você pode habilitar o compartilhamento de cache de token no iOS.

Protegendo o aplicativo em si com o Intune

Seu aplicativo móvel (escrito em Xamarin.iOS ou Xamarin. O Android) pode ter políticas de proteção de aplicativo aplicadas a ele, para que ele possa ser gerenciado pelo InTune e reconhecido pelo Intune como um aplicativo gerenciado. O SDK do InTune é separado da MSAL e conversa para Microsoft Entra ID por conta própria.

Aplicativo daemon de área de trabalho ou serviço que chama uma API Web como ela mesma (em seu próprio nome)

Você pode escrever um aplicativo daemon que adquire um token usando sua própria identidade na parte superior usando os métodos de aquisição de credenciais de cliente do ConfidentialClientApplication da MSAL.NET. Eles supõem que o aplicativo tenha registrado anteriormente um segredo (senha ou certificado do aplicativo) com Microsoft Entra ID, que ele compartilha com essa chamada.

Aplicativo da área de trabalho que chama uma API Web em nome de um usuário conectado

Os aplicativos da área de trabalho podem usar a mesma autenticação interativa que os aplicativos móveis.

Para Windows aplicativos hospedados, também é possível que aplicativos em execução em computadores ingressados em um domínio Windows ou Microsoft Entra unidos para adquirir um token silenciosamente usando a Autenticação integrada de Windows.

Se o aplicativo da área de trabalho for um aplicativo .NET Core em execução no Linux ou mac, você não poderá usar o fluxo de autenticação interativa (já que .NET Core não fornece um navegador da Web) nem a Autenticação integrada Windows. A melhor opção nesse caso é usar o fluxo de código do dispositivo, conforme explicado no Aplicativo sem um navegador ou aplicativo iOT chamando uma API no nome do usuário.

Embora não seja recomendado, você pode usar o fluxo nome de usuário-senha em aplicativos cliente públicos; Ele ainda é necessário em alguns cenários (como DevOps), mas cuidado que usá-lo impõe restrições ao seu aplicativo. Por exemplo, você não pode conectar usuários que precisam executar a Autenticação Multifator (acesso condicional) ou aproveitar os benefícios do SSO (logon único). O fluxo nome de usuário-senha vai contra os princípios da autenticação moderna e é fornecido apenas por motivos herdados.

Em aplicativos da área de trabalho, se você quiser que o cache de token seja persistente, você deverá personalizar a serialização do cache de token.

Aplicativo sem navegador ou aplicativo iOT chamando uma API no nome do usuário

Os aplicativos em execução em um dispositivo sem um navegador ainda poderão chamar uma API em nome de um usuário, depois de fazer com que o usuário entre em outro dispositivo que tenha um navegador da Web. Para isso, você precisará usar o fluxo de Código do Dispositivo

API Web chamando outra API Web downstream no nome do usuário para quem ele foi chamado

Se você quiser que seu ASP.NET ou ASP.NET Core API Web protegida chame outra API Web em nome do usuário representado pelo token de acesso foi usado para chamá-lo de API, você precisará:

• Valide o token. Para isso, você usará o middleware JWT ASP.NET sob o capô. Isso também envolve validar o token que é feito pelas extensões IdentityModel para .NET biblioteca, não MSAL.NET
• Em seguida, você precisará adquirir um token para a API Web downstream usando o método ConfidentialClientApplication Adquirindo um token em nome de um usuário em chamadas de serviço a serviço.
• As APIs Web que chamam outra API Web também precisarão fornecer uma serialização de cache personalizada.

API Web chamando outra API em seu próprio nome

Assim como em aplicativos daemon de área de trabalho ou serviço, uma API Web daemon (ou um aplicativo Web daemon) pode usar os métodos de aquisição de credenciais de cliente do ConfidentialClientApplication da MSAL.NET.

Recursos do Transverse

Em todos os cenários, talvez você queira:

• Solucionar problemas ativando logs ou Telemetria
• Entenda como reagir a exceções devido ao serviço MsalServiceExceptionMicrosoft Entra ou a algo errado acontecendo no próprio clienteMsalClientException
• Usar MSAL.NET com um proxy