Aquisição de token

Tipos de aplicativos

Conforme explicado em Cenários, há muitas maneiras de adquirir um token com MSAL.NET. Alguns exigem interação e outros são completamente transparentes para o usuário. A abordagem usada para adquirir um token é diferente dependendo se o desenvolvedor está criando um cliente público (desktop ou móvel) ou um aplicativo cliente confidencial (aplicativo Web, API Web ou daemon como um serviço de Windows). Os clientes públicos geralmente exigem interação do usuário, enquanto os clientes confidenciais dependem de credenciais pré-provisionadas, como certificados e segredos.

Armazenamento de token em cache

Para aplicativos cliente públicos e confidenciais, MSAL.NET dá suporte à adição de um cache de token que preserva tokens de autenticação e atualização, bem como os atualiza proativamente conforme necessário. Para obter detalhes, consulte Serialização de cache de token em MSAL.NET.

Para .NET aplicativos da área de trabalho (.NET, .NET Framework e .NET Core), o aplicativo precisa lidar diretamente com a serialização e o armazenamento do cache de token; no entanto, as classes auxiliares estão disponíveis para ajudar a simplificar o processo.

Métodos de aquisição de token

Aplicativos cliente públicos

• Geralmente, adquirirá o token interativamente, fazendo com que o usuário entre.
• Também é possível que um aplicativo da área de trabalho em execução em um computador Windows ingressado em um domínio ou Microsoft Entra ID use a IWA /Kerberos (Autenticação integrada de Windows) para adquirir um token silenciosamente.
  • Tenha em mente que a abordagem IWA não é recomendada. Uma abordagem mais segura usando o WAM (Gerenciador de Contas Web) está disponível.
• Para aplicativos de área de trabalho do .NET Framework, em cenários limitados, é possível obter um token com um nome de usuário e senha. Devido a considerações de segurança, essa abordagem não é recomendada.
• Em aplicativos em execução em dispositivos que não têm um navegador da Web, um token pode ser adquirido com a ajuda do fluxo de código do dispositivo, que fornece ao usuário do aplicativo uma URL e um código. O usuário irá posteriormente para um navegador da Web em outro dispositivo, inserirá o código e entrará. Em seguida, o dispositivo de autenticação sondará Microsoft Entra ID serviços até receber a confirmação de uma entrada bem-sucedida e de um token de acesso.

A tabela a seguir resume as abordagens disponíveis para adquirir tokens em aplicativos cliente públicos:

Aplicativos cliente confidenciais

• Adquire token para o próprio aplicativo, não para um usuário. A aquisição de token é feita com a ajuda das credenciais do cliente. Esse fluxo é útil para sincronizar ferramentas ou ferramentas que processam dados ou informações do usuário sem uma identidade específica anexada a ele.
• Para APIs Web que chamam uma API em nome de um usuário, os desenvolvedores podem usar em nome do fluxo. O próprio aplicativo usará as credenciais do cliente para adquirir um token com base em uma declaração de usuário (por exemplo, SAML ou JWT). Esse fluxo pode ser usado para aplicativos que precisam acessar recursos de um usuário específico em chamadas de serviço a serviço.
• Para aplicativos Web, a aquisição de token é feita usando um código de autorização depois de assinar o usuário por meio da URL de solicitação de autorização. Normalmente, esse é o mecanismo usado por um aplicativo que permite que o usuário entre usando o OpenID Connect e acesse APIs Web em nome desse usuário específico.

A tabela a seguir resume as maneiras de adquirir tokens em aplicativos cliente confidenciais:

Padrão para adquirir tokens no MSAL.NET

Todos os métodos de Aquisição de Token em MSAL.NET têm o seguinte padrão:

• No aplicativo, você chama o método AcquireTokenXXX correspondente ao fluxo que deseja usar, passando os parâmetros obrigatórios para esse fluxo (em fluxo geral)
• Isso retorna um construtor de comandos, no qual você pode adicionar parâmetros opcionais usando . Com métodosYYY
• Em seguida, você chama ExecuteAsync() para obter o resultado da autenticação.

Aqui está o padrão:

AuthenticationResult result = app.AcquireTokenXXX(mandatory-parameters)
 .WithYYYParameter(optional-parameter)
 .ExecuteAsync();

AuthenticationResultpropriedades no MSAL.NET

Em todos os casos acima, os métodos para adquirir tokens retornam um AuthenticationResult (ou no caso dos métodos assíncronos um Task<AuthenticationResult>.

Em MSAL.NET, AuthenticationResult expõe:

• AccessToken para a API Web acessar recursos. Essa é uma cadeia de caracteres, geralmente um JWT codificado em base64, mas o cliente nunca deve olhar dentro do token de acesso. Não há garantia de que o formato permaneça estável e pode ser criptografado para o recurso. As pessoas que escrevem código dependendo do conteúdo do token de acesso no cliente são uma das maiores fontes de erros e quebras lógicas do cliente
• IdToken para o usuário (este é um JWT)
• ExpiresOn informa a data/hora em que o token expira
• TenantId contém o locatário em que o usuário foi encontrado. Observe que, no caso de usuários convidados (Microsoft Entra cenários B2B), o TenantId é o locatário convidado, não o locatário exclusivo. Quando o token é entregue no nome de um usuário, AuthenticationResult também contém informações sobre esse usuário. Para fluxos de cliente confidenciais em que os tokens são solicitados sem nenhum usuário (para o aplicativo), essas informações do usuário são nulas.
• Para Scopes o qual o token foi emitido (consulte escopos e não recursos)
• A ID exclusiva para o usuário.

IAccount

MSAL.NET define a noção de Conta (por meio da IAccount interface). Essa alteração interruptiva fornece a semântica certa: o fato de que o mesmo usuário pode ter várias contas, em diretórios Microsoft Entra diferentes. Além disso, MSAL.NET fornece informações melhores no caso de cenários de convidado, pois as informações da conta inicial são fornecidas. O diagrama a seguir mostra a estrutura da IAccount interface:

A AccountId classe identifica uma conta em um locatário específico. Tem as seguintes propriedades:

A interface IAccount representa informações sobre uma única conta. O mesmo usuário pode estar presente em locatários diferentes, ou seja, um usuário pode ter várias contas. Seus membros são: