MSAL.NET gebruiken om gebruikers aan te melden met sociale identiteiten

Important

Vanaf 1 mei 2025 is Azure AD B2C niet meer beschikbaar voor nieuwe klanten. Meer informatie vindt u in onze veelgestelde vragen.

U kunt MSAL.NET gebruiken om gebruikers met sociale identiteiten aan te melden met behulp van Azure AD B2C. Azure AD B2C is gebaseerd op het begrip beleid. In MSAL.NET komt het opgeven van een beleidsregel neer op het opgeven van een authority.

  • Wanneer u de openbare client-applicatie instantiateert, moet u het beleid opgeven in de authority
  • Wanneer u een beleid wilt toepassen, moet u een override van AcquireTokenInteractive aanroepen met een parameter van het type authority

Autoriteit voor een Azure AD B2C-tenant en beleid

De instantie die moet worden gebruikt, is https://login.microsoftonline.com/tfp/{tenant}/{policyName} waar:

  • tenantis de naam van de Azure AD B2C-tenant,
  • policyName de naam van het beleid dat moet worden toegepast (bijvoorbeeld 'b2c_1_susi' voor aanmelding/registratie).

De huidige richtlijn van B2C is om b2clogin.com als autoriteit te gebruiken. Bijvoorbeeld: $"https://{your-tenant-name}.b2clogin.com/tfp/{your-tenant-ID}/{policyname}". Zie Omleidings-URL's instellen voor b2clogin.com voor meer informatie.

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

De toepassing instantiëren

Bij het bouwen van de toepassing moet u, zoals gebruikelijk, de instantie opgeven die is gebouwd zoals hierboven

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

Een token verkrijgen om een beleid toe te passen

Note

Vanaf MSAL .NET 4.15.0 hoeven ontwikkelaars hun eigen cachefilterlogica niet meer te schrijven.

In Azure AD B2C is elk beleid of elke gebruikersstroom een afzonderlijke autorisatieserver. Ze geven hun eigen tokens uit. Een token dat is verkregen met behulp van de b2c_1_editprofile gebruikersstroom werkt dus niet met een resource die is beveiligd achter een b2c_1_susi gebruikersstroom. Daarom moeten toepassingsontwikkelaars bij het aanroepen van een beveiligde API MSAL laten weten welk token moet worden gebruikt vanuit de cache, op basis van de gebruikersstroom waarop het doel is.

Voor het verkrijgen van een token voor een Azure met AD B2C beveiligde API in een openbare clienttoepassing moet u het volgende gebruiken:

  • De override van GetAccountsAsync() met een gebruikersstroom voordat AcquireTokenSilent wordt aangeroepen,
  • Overschrijft AcquireTokenInteractive met een B2C-authority:
IEnumerable<IAccount> accounts = await application.GetAccountsAsync(B2CConstants.PolicySignUpSignIn);
AuthenticationResult ar = await application.AcquireTokenInteractive(B2CConstants.Scopes)
                                           .WithAccount(accounts.FirstOrDefault())
                                           .ExecuteAsync();

In versie > 4.15.0 moesten ontwikkelaars hun eigen cachefilterlogica schrijven. Dit is niet langer het geval in >= 4.15.0, omdat ontwikkelaars alleen het beleid of de gebruikersstroom hoeven op te geven, en MSAL retourneert het bijbehorende account voor die specifieke gebruikersstroom.

In MSAL.NET schrijft u alleen het volgende:In MSAL < 4.15.0 moest u schrijven:
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;
}

Het toepassen van een beleid (bijvoorbeeld om de eindgebruiker het profiel te laten bewerken of het wachtwoord opnieuw in te stellen) wordt momenteel uitgevoerd door AcquireTokenInteractive aan te roepen.

Houd er rekening mee dat u in het geval van deze twee beleidsregels het geretourneerde token/verificatieresultaat niet gebruikt.

Speciaal geval van EditProfile- en ResetPassword-beleid

Wanneer u een ervaring wilt bieden waarbij uw eindgebruikers zich aanmelden met een sociale identiteit en vervolgens hun profiel bewerken, moet u het B2C EditProfile-beleid toepassen. De manier om dit te doen, is door AcquireTokenInteractive aan te roepen met de specifieke authority voor dat beleid en Prompt in te stellen op Prompt.NoPrompt om te voorkomen dat het dialoogvenster voor accountselectie wordt weergegeven (omdat de gebruiker al is aangemeld)

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

Nu in preview: zelfservice voor wachtwoord opnieuw instellen, wat betekent dat de nieuwe mogelijkheid om wachtwoorden opnieuw in te stellen nu deel uitmaakt van de gebruikersstromen voor aanmelden of registreren/aanmelden (aanbevolen). Dit betekent ook dat nadat u deze preview-functie hebt ingeschakeld, u deze sectie met code kunt verwijderen:

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

Of welke speciale logica u hebt gedaan om de AADB2C90118 fout te verwerken.

Resource Owner Password Credentials (ROPC) met B2C

Zie de documentatie over de gebruikersnaam en wachtwoordstroom voor meer informatie over de ROPC-stroom.

Deze stroom wordt niet aanbevolen omdat uw toepassing een gebruiker vraagt om zijn wachtwoord niet veilig is. Zie voor meer informatie over dit probleem waarom Microsoft aan het werk is om wachtwoorden iets van het verleden te maken.

Door gebruikersnaam/wachtwoord te gebruiken, geeft u een aantal dingen op:

  • Kerntenants van moderne identiteit: wachtwoord wordt gevist, opnieuw afgespeeld. Omdat we het concept van een gedeeld geheim hebben dat kan worden onderschept. Dit is niet compatibel met wachtwoordloos.
  • Gebruikers die MFA moeten uitvoeren, kunnen zich niet aanmelden (omdat er geen interactie is)
  • Gebruikers kunnen geen eenmalige aanmelding uitvoeren

De ROPC-flow configureren in Azure AD B2C

Maak in uw Azure AD B2C-tenant een nieuwe gebruikersstroom en selecteer Aanmelden met ROPC. Hiermee schakelt u het ROPC-beleid voor uw tenant in. Zie De flow voor wachtwoordgegevens van de resource-eigenaar configureren voor meer informatie.

IPublicClientApplication bevat een methode met de naam AcquireTokenByUsernamePassword:

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

Deze methode neemt als parameters:

  • Het scopes om een toegangstoken aan te vragen voor
  • Een gebruikersnaam
  • Een SecureString-wachtwoord voor de gebruiker

Vergeet niet om de instantie te gebruiken die het ROPC-beleid bevat.

Beperkingen van de ROPC-stroom

Deze stroom werkt alleen voor lokale accounts (waarbij u zich registreert bij B2C met behulp van een e-mailadres of gebruikersnaam). Deze procedure werkt niet bij federatie met een van de door B2C ondersteunde IdP's (Facebook, Google, enzovoort).

Google-authenticatie en ingesloten webweergave

Als u een B2C-ontwikkelaar bent die Google als id-provider gebruikt, raden we u aan de systeembrowser te gebruiken, omdat Google geen verificatie van ingesloten webweergaven toestaat. login.microsoftonline.com Momenteel is het een vertrouwde instantie met Google. Het gebruik van deze authority werkt met een ingesloten webview. Het gebruik b2clogin.com is echter geen vertrouwde instantie bij Google, dus gebruikers kunnen zich niet verifiëren.

Caching met B2C in MSAL.NET

Bekend probleem met Azure AD B2C

MSAL.Net ondersteunt een tokencache. De tokencachingsleutel is gebaseerd op de claims die worden geretourneerd door de id-provider. Momenteel heeft MSAL.Net twee claims nodig om een tokencachesleutel te bouwen:

  1. tid dat is de tenant-id van Microsoft Entra
  2. preferred_username

Beide claims ontbreken in veel van de Azure AD B2C-scenario's.

De impact voor de klant is als volgt: wanneer u probeert het veld voor de gebruikersnaam weer te geven, krijgt u dan "Missing from the token response" te zien als waarde? Als dit het geval is, is dit omdat B2C geen waarde retourneert in het IdToken voor de preferred_username vanwege beperkingen met de sociale accounts en externe id-providers (IdPs). Microsoft Entra ID retourneert een waarde voor preferred_username omdat deze weet wie de gebruiker is, maar voor B2C, omdat de gebruiker zich kan aanmelden met een lokaal account, Facebook, Google, GitHub, enzovoort... er is geen consistente waarde voor B2C die moet worden gebruikt voor preferred_username. Om MSAL te deblokkeren van de implementatie van cachecompatibiliteit met ADAL, hebben we besloten om 'Missing from the token response' aan onze kant te gebruiken bij het verwerken van de B2C-accounts wanneer het IdToken niets retourneert voor preferred_username. MSAL moet een waarde retourneren voor preferred_username om de cachecompatibiliteit tussen bibliotheken te behouden.

Tijdelijke oplossingen

Beperking van het gebrek aan tid

De voorgestelde tijdelijke oplossing is gebruik te maken van caching op basis van beleid.

U kunt de tid claim ook gebruiken als u het aangepaste B2C-beleid gebruikt, omdat het de mogelijkheid biedt om extra claims naar de toepassing te retourneren. Meer informatie over Claims Transformation.

Oplossing voor "Ontbreekt in de tokenrespons"

Een optie is om de claim 'name' te gebruiken als de voorkeursgebruikersnaam. Het proces wordt over het algemeen vermeld in dit B2C-document:

"Kies in de kolom Retourclaim de claims die u wilt retourneren in de autorisatietokens die worden teruggestuurd naar uw toepassing na een geslaagde bewerking van het profiel. Selecteer bijvoorbeeld de weergavenaam en de postcode.”

De gebruikersinterface aanpassen

Pas de gebruikersinterface aan met Azure AD B2C.

  • Last updated on