Usando o MSAL.NET para permitir que usuários entrem com identidades sociais

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais em nossas perguntas frequentes.

Você pode usar MSAL.NET para conectar usuários com identidades sociais usando Azure AD B2C. Azure AD B2C é criado em torno da noção de políticas. Em MSAL.NET, especificar uma política se traduz em fornecer uma autoridade.

  • Ao instanciar o aplicativo cliente público, você precisa especificar a política no parâmetro authority.
  • Quando quiser aplicar uma política, será necessário chamar uma versão sobrescrita de AcquireTokenInteractive que contém um parâmetro authority

Autoridade para um locatário Azure AD B2C e uma política

A autoridade a ser usada é https://login.microsoftonline.com/tfp/{tenant}/{policyName} onde:

  • tenant é o nome do locatário do Azure AD B2C
  • policyName o nome da política a ser aplicada (por exemplo, "b2c_1_susi" para entrada/registro).

A orientação atual do B2C é usar b2clogin.com como autoridade. Por exemplo, $"https://{your-tenant-name}.b2clogin.com/tfp/{your-tenant-ID}/{policyname}". Para obter mais informações, consulte Definir URLs de redirecionamento para b2clogin.com..

// Azure AD B2C Coordinates
public static string Tenant = "fabrikamb2c.onmicrosoft.com";
public static string ClientID = "00001111-aaaa-2222-bbbb-3333cccc4444";
public static string PolicySignUpSignIn = "b2c_1_susi";
public static string PolicyEditProfile = "b2c_1_edit_profile";
public static string PolicyResetPassword = "b2c_1_reset";

public static string AuthorityBase = $"https://fabrikamb2c.b2clogin.com/tfp/{Tenant}/";
public static string Authority = $"{AuthorityBase}{PolicySignUpSignIn}";
public static string AuthorityEditProfile = $"{AuthorityBase}{PolicyEditProfile}";
public static string AuthorityPasswordReset = $"{AuthorityBase}{PolicyResetPassword}";

Instanciando o aplicativo

Ao criar o aplicativo, você precisa fornecer, como de costume, a autoridade, criada como acima

application = PublicClientApplicationBuilder.Create(ClientID)
               .WithB2CAuthority(Authority)
               .Build();

Adquirir um token para aplicar uma política

Note

A partir do MSAL .NET 4.15.0, os desenvolvedores não precisarão mais escrever sua própria lógica de filtragem de cache.

No Azure AD B2C, cada política ou fluxo de usuário é um servidor de autorização separado. Eles emitem seus próprios tokens. Portanto, um token adquirido usando o fluxo de usuário b2c_1_editprofile não funcionará com um recurso protegido por um fluxo de usuário b2c_1_susi. Portanto, ao chamar uma API protegida, os desenvolvedores de aplicativos devem informar a MSAL qual token usar do cache, com base no fluxo de usuário que será direcionado.

A aquisição de um token para uma API protegida do AD B2C do Azure em um aplicativo cliente público exige que você use:

  • A substituição de GetAccountsAsync() por um fluxo de usuário antes de chamar AcquireTokenSilent,
  • As substituições AcquireTokenInteractive com uma autoridade B2C:
IEnumerable<IAccount> accounts = await application.GetAccountsAsync(B2CConstants.PolicySignUpSignIn);
AuthenticationResult ar = await application.AcquireTokenInteractive(B2CConstants.Scopes)
                                           .WithAccount(accounts.FirstOrDefault())
                                           .ExecuteAsync();

Nas versões > 4.15.0, os desenvolvedores tinham que escrever sua própria lógica de filtragem de cache. Esse não é mais o caso em >= 4.15.0, pois os desenvolvedores só precisam especificar a política ou o fluxo do usuário, e a MSAL retornará a conta correspondente para esse fluxo de usuário específico.

Em MSAL.NET, você só escreve:No MSAL < 4.15.0, você precisava escrever:
var accounts = await app.GetAccountsAsync(App.PolicySignUpSignIn);
private IAccount GetAccountByPolicy(IEnumerable<IAccount> accounts, string policy)
{
 foreach (var account in accounts)
 {
  string userIdentifier = account.HomeAccountId.ObjectId.Split('.')[0];
  if (userIdentifier.EndsWith(policy.ToLower()))
   return account;
 }
 return null;
}

A aplicação de uma política (por exemplo, permitir que o usuário final edite seu perfil ou redefina sua senha) é feita no momento chamando AcquireTokenInteractive.

Observe que, no caso dessas duas políticas, você não usa o token retornado / resultado da autenticação.

Caso especial de políticas EditProfile e ResetPassword

Quando você quiser fornecer uma experiência em que os usuários finais entrem com uma identidade social e editem seu perfil, você deseja aplicar a política B2C EditProfile. A maneira de fazer isso é chamar AcquireTokenInteractive com a autoridade específica dessa política e um Prompt definido como Prompt.NoPrompt, para evitar que a caixa de diálogo de seleção de conta seja exibida (já que o usuário já iniciou a sessão)

private async void EditProfileButton_Click(object sender, RoutedEventArgs e)
{
 IEnumerable<IAccount> accounts = await app.GetAccountsAsync();
 try
 {
  var authResult = await app.AcquireToken(scopes:App.ApiScopes)
                               .WithAccount(GetUserByPolicy(accounts, App.PolicyEditProfile)),
                               .WithPrompt(Prompt.NoPrompt),
                               .WithB2CAuthority(App.AuthorityEditProfile)
                               .ExecuteAsync();
  DisplayBasicTokenInfo(authResult);
 }
 catch
 {
  . . .
}

Agora a redefinição de senha self-service está em versão preliminar, o que significa que a nova experiência de redefinição de senha agora faz parte dos fluxos de usuário de entrada ou inscrição/entrada (recomendado). Isso também significa que, depois de habilitar esse recurso de visualização, você pode remover esta seção do código:

 if (ex.Message.Contains("AADB2C90118"))
{
       authResult = await app.AcquireTokenInteractive(App.ApiScopes)
              .WithParentActivityOrWindow(new WindowInteropHelper(this).Handle)
              .WithPrompt(Prompt.SelectAccount)
              .WithB2CAuthority(App.AuthorityResetPassword)
              .ExecuteAsync();
}

Ou qualquer lógica especial que você estava usando para processar o erro AADB2C90118.

Credenciais de senha do proprietário do recurso (ROPC) no B2C

Para obter mais detalhes sobre o fluxo ROPC, consulte a documentação de fluxo de nome de usuário e senha.

Esse fluxo não é recomendado porque seu aplicativo solicitando a senha de um usuário não é seguro. Para obter mais informações sobre esse problema, consulte por que Microsoft está trabalhando para tornar as senhas uma coisa do passado.

Usando o nome de usuário/senha, você está desistindo de várias coisas:

  • Princípios centrais da identidade moderna: a senha é obtida por phishing e reutilizada. Porque temos esse conceito de um segredo de compartilhamento que pode ser interceptado. Isso é incompatível com a falta de senha.
  • Os usuários que precisam fazer MFA não poderão entrar (pois não há interação)
  • Os usuários não poderão fazer logon único

Configurar o fluxo ROPC no Azure AD B2C

No seu locatário do Azure AD B2C, crie um novo fluxo de usuário e selecione Entrar com ROPC. Isso habilitará a política ROPC para seu locatário. Consulte Configurar o fluxo de credenciais de senha do proprietário do recurso para obter mais detalhes.

IPublicClientApplication contém um método chamado AcquireTokenByUsernamePassword:

AcquireTokenByUsernamePassword(
            IEnumerable<string> scopes,
            string username,
            SecureString password)

Esse método usa como parâmetros:

  • O scopes para o qual solicitar um token de acesso
  • Um nome de usuário
  • Uma senha SecureString para o usuário

Lembre-se de usar a autoridade que contém a política ROPC.

Limitações do fluxo ROPC

Esse fluxo só funciona para contas locais (em que você se registra no B2C usando um email ou nome de usuário). Esse fluxo não funciona ao federar com qualquer um dos IdPs suportados pelo B2C (Facebook, Google etc.).

Autenticação do Google e WebView incorporada

Se você for um desenvolvedor B2C usando o Google como um provedor de identidade, recomendamos que você use o navegador do sistema, pois o Google não permite a autenticação de visões da Web inseridas. Atualmente, login.microsoftonline.com é uma autoridade confiável com o Google. O uso dessa autoridade funcionará com o modo de exibição da Web incorporado. No entanto, o uso b2clogin.com não é uma autoridade confiável com o Google, portanto, os usuários não poderão se autenticar.

Armazenamento em cache com o B2C no MSAL.NET

Problema conhecido com Azure AD B2C

MSAL.Net dá suporte a um cache de token. A chave de cache do token é baseada nas declarações de identidade retornadas pelo provedor de identidade. Atualmente, MSAL.Net precisa de duas declarações para criar uma chave de cache de token:

  1. tid que é a ID do locatário do Microsoft Entra
  2. preferred_username

Ambas as declarações estão ausentes em muitos dos cenários do AD B2C Azure.

O impacto para o cliente é que, ao tentar exibir o campo de nome de usuário, você recebe “Ausente da resposta do token” como valor? Nesse caso, isso ocorre porque o B2C não retorna um valor no IdToken para o preferred_username devido a limitações com as contas sociais e os IdPs (provedores de identidade externos). Microsoft Entra ID retorna um valor para preferred_username porque sabe quem é o usuário, mas para B2C, porque o usuário pode entrar com uma conta local, Facebook, Google, GitHub etc... não há um valor consistente para B2C usar para preferred_username. Para viabilizar que a MSAL implemente a compatibilidade do cache com a ADAL, decidimos usar “Ausente da resposta do token” do nosso lado ao lidar com contas B2C quando o IdToken não retorna nada para preferred_username. O MSAL deve retornar um valor para preferred_username para manter a compatibilidade do cache entre bibliotecas.

Soluções alternativas

Mitigação da falta de tid

A solução alternativa sugerida é usar o cache por Política.

Como alternativa, você pode usar a tid declaração, se estiver usando as políticas personalizadas B2C, pois ela fornece a capacidade de retornar declarações adicionais ao aplicativo. Para saber mais sobre Claims Transformation.

Mitigação para "ausente da resposta do token"

Uma opção é usar a declaração "name" como o nome de usuário preferencial. O processo geralmente é mencionado neste documento B2C:

Na coluna Retornar declaração, escolha as declarações que você quer retornar nos tokens de autorização enviados de volta ao aplicativo após uma experiência de edição de perfil com êxito. Por exemplo, selecione Nome de Exibição, CEP.”

Personalizando a interface do usuário

Personalize a interface do usuário com Azure AD B2C.