Usar o MSAL.NET para iniciar sessão de utilizadores com identidades sociais

Pode usar o MSAL.NET para iniciar sessão de utilizadores com identidades sociais usando o Azure AD B2C. O Azure AD B2C é construído em torno da noção de políticas. No MSAL.NET, especificar uma política traduz-se em fornecer uma autoridade.

• Quando crias a aplicação cliente pública, tens de especificar a política na autoridade
• Quando queres aplicar uma política, precisas de chamar um override de AcquireTokenInteractive que contém um authority parâmetro

Autoridade de um tenant e política do Azure AD B2C

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

• tenanté o nome do inquilino B2C do Azure AD,
• policyName o nome da política a aplicar (por exemplo, "b2c_1_susi" para iniciar sessão/registo).

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 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}";

Instanciar a aplicação

Ao compilar a aplicação, tem de fornecer, como habitual, a autoridade, conforme indicado acima.

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

Aquisição de um token para aplicar uma política

No Azure AD B2C, cada política, ou fluxo de utilizador, é um servidor de autorização separado. Eles emitem os seus próprios tokens. Assim, um token adquirido através do b2c_1_editprofile fluxo de utilizador não funcionará com um recurso protegido atrás de um b2c_1_susi fluxo de utilizador. Portanto, ao chamar uma API protegida, os programadores de aplicações devem informar à MSAL qual o token a usar da cache, com base no fluxo de utilizador que será direcionado.

Adquirir um token para uma API protegida Azure AD B2C numa aplicação cliente pública requer que utilize:

• A substituição do GetAccountsAsync() com um fluxo de utilizador antes de chamar o AcquireTokenSilent,
• Substitui o AcquireTokenInteractive por 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 programadores tinham de escrever a sua própria lógica de filtragem de cache. Isto já não acontece em >= 4.15.0, pois os programadores só precisam de especificar a política ou fluxo de utilizador, e a MSAL devolverá a conta correspondente para esse fluxo de utilizador específico.

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;
}

Aplicar uma política (por exemplo, permitir que o utilizador final edite o seu perfil ou redefina a palavra-passe) é atualmente feito ligando para a AcquireTokenInteractive.

Tenha em atenção que, no caso destas duas políticas, não se utiliza o token devolvido nem o resultado da autenticação.

Caso especial das políticas EditProfile e ResetPassword

Quando quiser proporcionar uma experiência em que os seus utilizadores finais iniciem sessão com uma identidade social e depois editem o perfil, deve aplicar a política B2C EditProfile. A forma de o fazer é invocar AcquireTokenInteractive com a autoridade específica dessa política e com o Prompt definido como Prompt.NoPrompt para evitar que o diálogo de seleção de conta seja apresentado (pois o utilizador já tem sessão iniciada)

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
 {
  . . .
}

Está agora disponível em pré-visualização a redefinição de palavra-passe por autosserviço, o que significa que a nova experiência de redefinição de palavra-passe passa agora a fazer parte dos fluxos de utilizador de início de sessão ou de registo/início de sessão (Recomendado). Isto também significa que, uma vez ativada esta funcionalidade de pré-visualização, pode remover esta secçã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 estivesses a usar para processar o AADB2C90118 erro.

Credenciais de Palavra-passe do Proprietário do Recurso (ROPC) com B2C

Para mais detalhes sobre o fluxo ROPC, consulte a documentação do fluxo de nomes de utilizador e palavra-passe.

Este fluxo não é recomendado

Este fluxo não é recomendado porque a sua aplicação a pedir a palavra-passe a um utilizador não é segura. Para mais informações sobre este problema, veja porque é que a Microsoft está a trabalhar para tornar as palavras-passe algo do passado.

Ao usar nome de utilizador/palavra-passe está a abdicar de várias coisas:

• Princípios centrais da identidade moderna: a palavra-passe é apanhada, reproduzida. Porque temos este conceito de um segredo de partilha que pode ser intercetado. Isto é incompatível com a autenticação sem palavra-passe.
• Os utilizadores que precisam de fazer MFA não poderão iniciar sessão (pois não há interação)
• Os utilizadores não poderão fazer login único

Configurar o fluxo ROPC no Azure AD B2C

No seu tenant B2C do Azure AD, crie um novo fluxo de utilizador e selecione Iniciar sessão usando ROPC. Isto permitirá a apólice ROPC para o seu inquilino. Consulte Configurar o fluxo de credenciais de palavra-passe do proprietário do recurso para mais detalhes.

IPublicClientApplication contém um método chamado AcquireTokenByUsernamePassword:

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

Este método toma como parâmetros:

• O scopes para solicitar um token de acesso para
• Um nome de utilizador
• Uma palavra-passe SecureString para o utilizador

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

Limitações do fluxo ROPC

Este fluxo só funciona para contas locais (onde se regista em B2C usando um email ou nome de utilizador). Este fluxo não funciona se houver federação com qualquer um dos IdPs suportados pelo B2C (Facebook, Google, etc.).

Autenticação Google e vista Web incorporada

Se for um programador B2C que utiliza a Google como fornecedor de identidade, recomendamos que utilize o navegador do sistema, pois a Google não permite autenticação a partir de webviews incorporados. Atualmente, login.microsoftonline.com é uma autoridade de confiança junto da Google. A utilização desta autorização funcionará com a WebView incorporada. No entanto, o uso b2clogin.com não é uma autoridade de confiança junto da Google, pelo que os utilizadores não poderão autenticar-se.

Armazenamento em cache com B2C no MSAL.NET

Problema conhecido com o Azure AD B2C

MSAL.Net suporta uma cache de tokens. A chave de cache do token baseia-se nas declarações retornadas pelo Fornecedor de Identidade. Atualmente, MSAL.Net precisa de duas reivindicações para construir uma chave de cache de token:

1. tid que é o ID do tenant do Microsoft Entra
2. preferred_username

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

O impacto para o cliente é o seguinte: ao tentar apresentar o campo do nome de utilizador, obtém "Em falta na resposta do token" como valor? Se assim for, isto deve-se ao facto de o B2C não devolver um valor no IdToken para o preferred_username devido a limitações das contas sociais e dos fornecedores externos de identidade (IdPs). Microsoft Entra ID devolve um valor para preferred_username porque sabe quem é o utilizador, mas para B2C, porque o utilizador pode iniciar sessão com uma conta local, Facebook, Google, GitHub, etc... não existe um valor consistente para B2C usar para preferred_username. Para permitir que a MSAL avance com a implementação da compatibilidade da cache com o ADAL, decidimos usar "Missing from the token response" internamente ao lidar com contas B2C quando o IdToken não devolve nenhum valor para preferred_username. O MSAL deve devolver um valor para preferred_username para manter a compatibilidade da cache entre bibliotecas.

Soluções

Mitigação da falta de tid

A solução alternativa sugerida é usar o caching por política.

Em alternativa, pode utilizar a tid declaração, se estiver a usar as políticas personalizadas do B2C, porque permite devolver declarações adicionais à aplicação. Para saber mais sobre Claims Transformation.

Mitigação para "Falta na resposta do token"

Uma opção é usar a reivindicação "nome" como nome de utilizador preferido. O processo é geralmente mencionado neste documento B2C:

"Na coluna de Devolução de reclamação, escolha as reivindicações que quer que sejam devolvidas nos tokens de autorização enviados de volta à sua candidatura após uma experiência bem-sucedida de edição de perfil. Por exemplo, selecione Nome de Exibir, Código Postal."

Personalização da interface de utilizador

Personalize a interface do utilizador com o Azure AD B2C.