Authentifier les utilisateurs avec Azure Active Directory B2C

Télécharger l’exemple Télécharger l’exemple

Azure Active Directory B2C fournit la gestion des identités cloud pour les applications web et mobiles destinées aux consommateurs. Cet article explique comment utiliser Azure Active Directory B2C pour intégrer la gestion des identités dans une application mobile avec la bibliothèque d’authentification Microsoft.

Vue d’ensemble

Azure Active Directory B2C (ADB2C) est un service de gestion des identités pour les applications destinées aux consommateurs. Il permet aux utilisateurs de se connecter à votre application à l’aide de leurs comptes de réseaux sociaux existants ou d’informations d’identification personnalisées telles que l’e-mail ou le nom d’utilisateur et le mot de passe. Les comptes d’informations d’identification personnalisés sont appelés comptes locaux .

Le processus d’intégration du service de gestion des identités Azure Active Directory B2C dans une application mobile est le suivant :

  1. Créer un locataire Azure Active Directory B2C.
  2. Inscrivez votre application mobile auprès du locataire Azure Active Directory B2C.
  3. Créez des stratégies pour l’inscription et la connexion, ainsi que pour les flux utilisateur de mot de passe oubliés.
  4. Utilisez la bibliothèque d’authentification Microsoft (MSAL) pour démarrer un flux de travail d’authentification avec votre locataire Azure Active Directory B2C.

Notes

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Azure Active Directory B2C prend en charge plusieurs fournisseurs d’identité, notamment Microsoft, GitHub, Facebook, Twitter et bien plus encore. Pour plus d’informations sur les fonctionnalités d’Azure Active Directory B2C, consultez la documentation Azure Active Directory B2C.

La bibliothèque d’authentification Microsoft prend en charge plusieurs architectures et plateformes d’application. Pour plus d’informations sur les fonctionnalités MSAL, consultez Bibliothèque d’authentification Microsoft sur GitHub.

Configurer un locataire Azure Active Directory B2C

Pour exécuter l’exemple de projet, vous devez créer un locataire Azure Active Directory B2C. Pour plus d’informations, consultez Créer un locataire Azure Active Directory B2C dans le Portail Azure.

Une fois que vous avez créé un locataire, vous aurez besoin du nom et de l’ID de locataire pour configurer l’application mobile. L’ID et le nom du locataire sont définis par le domaine généré lorsque vous avez créé votre URL de locataire. Si votre URL de locataire générée est https://contoso20190410tenant.onmicrosoft.com/l’ID de locataire et contoso20190410tenant.onmicrosoft.com le nom du locataire est .contoso20190410tenant Recherchez le domaine du locataire dans le Portail Azure en cliquant sur le filtre d’annuaire et d’abonnement dans le menu supérieur. La capture d’écran suivante montre le bouton de filtre d’annuaire et d’abonnement Azure et le domaine du locataire :

Nom du locataire dans l’affichage du filtre d’annuaire et d’abonnement Azure

Dans l’exemple de projet, modifiez le fichier Constants.cs pour définir les tenantName champs et tenantId . Le code suivant montre comment ces valeurs doivent être définies si votre domaine de locataire est https://contoso20190410tenant.onmicrosoft.com/, remplacez ces valeurs par des valeurs de votre portail :

public static class Constants
{
    static readonly string tenantName = "contoso20190410tenant";
    static readonly string tenantId = "contoso20190410tenant.onmicrosoft.com";
    ...
}

Inscrire votre application mobile auprès d’Azure Active Directory B2C

Une application mobile doit être inscrite auprès du locataire avant de pouvoir se connecter et authentifier les utilisateurs. Le processus d’inscription affecte un ID d’application unique à l’application et une URL de redirection qui redirige les réponses vers l’application après l’authentification. Pour plus d’informations, consultez Azure Active Directory B2C : Inscrire votre application. Vous devez connaître l’ID d’application attribué à votre application, qui est répertorié après le nom de l’application dans l’affichage des propriétés. La capture d’écran suivante montre où trouver l’ID d’application :

ID d’application dans la vue des propriétés de l’application Azure

La bibliothèque d’authentification Microsoft s’attend à ce que l’URL de redirection de votre application soit votre ID d’application avec le préfixe « msal » et suivi d’un point de terminaison appelé « auth ». Si votre ID d’application est « 1234abcd », l’URL complète doit être msal1234abcd://auth. Vérifiez que votre application a activé le paramètre client natif et créez un URI de redirection personnalisé à l’aide de votre ID d’application, comme illustré dans la capture d’écran suivante :

URI de redirection personnalisé dans la vue des propriétés de l’application Azure

L’URL sera utilisée ultérieurement dans les ApplicationManifest.xml Android et iOS Info.plist.

Dans l’exemple de projet, modifiez le fichier Constants.cs pour définir le clientId champ sur votre ID d’application. Le code suivant montre comment cette valeur doit être définie si votre ID d’application est 1234abcd:

public static class Constants
{
    static readonly string tenantName = "contoso20190410tenant";
    static readonly string tenantId = "contoso20190410tenant.onmicrosoft.com";
    static readonly string clientId = "1234abcd";
    ...
}

Créer des stratégies d’inscription et de connexion, et des stratégies de mot de passe oubliées

Une stratégie est une expérience que les utilisateurs doivent suivre pour effectuer une tâche telle que la création d’un compte ou la réinitialisation d’un mot de passe. Une stratégie spécifie également le contenu des jetons que l’application reçoit lorsque l’utilisateur revient de l’expérience. Vous devez configurer des stratégies pour l’inscription et la connexion au compte, et réinitialiser le mot de passe. Azure dispose de stratégies intégrées qui simplifient la création de stratégies communes. Pour plus d’informations, consultez Azure Active Directory B2C : Stratégies intégrées.

Une fois la configuration de la stratégie terminée, vous devez avoir deux stratégies dans la vue Flux d’utilisateurs (stratégies) dans le Portail Azure. La capture d’écran suivante illustre deux stratégies configurées dans le Portail Azure :

Deux stratégies configurées dans la vue Flux d’utilisateurs (stratégies) Azure

Dans l’exemple de projet, modifiez le fichier Constants.cs pour définir les policySignin champs et policyPassword pour refléter les noms que vous avez choisis lors de la configuration de la stratégie :

public static class Constants
{
    static readonly string tenantName = "contoso20190410tenant";
    static readonly string tenantId = "contoso20190410tenant.onmicrosoft.com";
    static readonly string clientId = "1234abcd";
    static readonly string policySignin = "B2C_1_signupsignin1";
    static readonly string policyPassword = "B2C_1_passwordreset";
    ...
}

Utiliser la bibliothèque d’authentification Microsoft (MSAL) pour l’authentification

Le package NuGet Microsoft Authentication Library (MSAL) doit être ajouté au projet partagé, au projet .NET Standard et aux projets de plateforme dans une Xamarin.Forms solution. MSAL inclut une PublicClientApplicationBuilder classe qui construit un objet adhérant à l’interface IPublicClientApplication . MSAL utilise des clauses With pour fournir des paramètres supplémentaires au constructeur et aux méthodes d’authentification.

Dans l’exemple de projet, le code derrière pour App.xaml définit les propriétés statiques nommées AuthenticationClient et UIParent, et instancie l’objet AuthenticationClient dans le constructeur. La WithIosKeychainSecurityGroup clause fournit un nom de groupe de sécurité pour les applications iOS. La WithB2CAuthority clause fournit l’autorité par défaut, ou stratégie, qui sera utilisée pour authentifier les utilisateurs. La WithRedirectUri clause indique à Azure Notification Hubs instance quel URI de redirection utiliser si plusieurs URI sont spécifiés. L’exemple suivant montre comment instancier le PublicClientApplication:

public partial class App : Application
{
    public static IPublicClientApplication AuthenticationClient { get; private set; }

    public static object UIParent { get; set; } = null;

    public App()
    {
        InitializeComponent();

        AuthenticationClient = PublicClientApplicationBuilder.Create(Constants.ClientId)
            .WithIosKeychainSecurityGroup(Constants.IosKeychainSecurityGroups)
            .WithB2CAuthority(Constants.AuthoritySignin)
            .WithRedirectUri($"msal{Constants.ClientId}://auth")
            .Build();

        MainPage = new NavigationPage(new LoginPage());
    }

    ...

Notes

Si votre instance Azure Notification Hubs n’a qu’un seul URI de redirection défini, le AuthenticationClient instance peut fonctionner sans spécifier l’URI de redirection avec la WithRedirectUri clause . Toutefois, vous devez toujours spécifier cette valeur au cas où votre configuration Azure se développerait pour prendre en charge d’autres clients ou méthodes d’authentification.

Le OnAppearing gestionnaire d’événements dans le code-behind LoginPage.xaml.cs appelle AcquireTokenSilentAsync pour actualiser le jeton d’authentification pour les utilisateurs qui se sont déjà connectés. Le processus d’authentification redirige vers le LogoutPage en cas de réussite et ne fait rien en cas d’échec. L’exemple suivant illustre le processus de réauthentification en mode silencieux dans OnAppearing:

public partial class LoginPage : ContentPage
{
    ...

    protected override async void OnAppearing()
    {
        try
        {
            // Look for existing account
            IEnumerable<IAccount> accounts = await App.AuthenticationClient.GetAccountsAsync();

            AuthenticationResult result = await App.AuthenticationClient
                .AcquireTokenSilent(Constants.Scopes, accounts.FirstOrDefault())
                .ExecuteAsync();

            await Navigation.PushAsync(new LogoutPage(result));
        }
        catch
        {
            // Do nothing - the user isn't logged in
        }
        base.OnAppearing();
    }

    ...
}

Le OnLoginButtonClicked gestionnaire d’événements (déclenché lorsque l’utilisateur clique sur le bouton Connexion) appelle AcquireTokenAsync. La bibliothèque MSAL ouvre automatiquement le navigateur de l’appareil mobile et accède à la page de connexion. L’URL de connexion, appelée Autorité, est une combinaison du nom de locataire et des stratégies définies dans le fichier Constants.cs . Si l’utilisateur choisit l’option mot de passe oublié, il est retourné à l’application avec une exception, qui lance l’expérience de mot de passe oublié. L’exemple suivant montre le processus d’authentification :

public partial class LoginPage : ContentPage
{
    ...

    async void OnLoginButtonClicked(object sender, EventArgs e)
    {
        AuthenticationResult result;
        try
        {
            result = await App.AuthenticationClient
                .AcquireTokenInteractive(Constants.Scopes)
                .WithPrompt(Prompt.SelectAccount)
                .WithParentActivityOrWindow(App.UIParent)
                .ExecuteAsync();

            await Navigation.PushAsync(new LogoutPage(result));
        }
        catch (MsalException ex)
        {
            if (ex.Message != null && ex.Message.Contains("AADB2C90118"))
            {
                result = await OnForgotPassword();
                await Navigation.PushAsync(new LogoutPage(result));
            }
            else if (ex.ErrorCode != "authentication_canceled")
            {
                await DisplayAlert("An error has occurred", "Exception message: " + ex.Message, "Dismiss");
            }
        }
    }

    ...
}

La OnForgotPassword méthode est similaire au processus de connexion, mais implémente une stratégie personnalisée. OnForgotPassword utilise une surcharge différente de AcquireTokenAsync, ce qui vous permet de fournir une autorité spécifique. L’exemple suivant montre comment fournir une autorité personnalisée lors de l’acquisition d’un jeton :

public partial class LoginPage : ContentPage
{
    ...
    async Task<AuthenticationResult> OnForgotPassword()
    {
        try
        {
            return await App.AuthenticationClient
                .AcquireTokenInteractive(Constants.Scopes)
                .WithPrompt(Prompt.SelectAccount)
                .WithParentActivityOrWindow(App.UIParent)
                .WithB2CAuthority(Constants.AuthorityPasswordReset)
                .ExecuteAsync();
        }
        catch (MsalException)
        {
            // Do nothing - ErrorCode will be displayed in OnLoginButtonClicked
            return null;
        }
    }
}

Le dernier élément d’authentification est le processus de déconnexion. La OnLogoutButtonClicked méthode est appelée lorsque l’utilisateur appuie sur le bouton de déconnexion. Il effectue une boucle dans tous les comptes et garantit que leurs jetons ont été invalidés. L’exemple ci-dessous illustre l’implémentation de la déconnexion :

public partial class LogoutPage : ContentPage
{
    ...
    async void OnLogoutButtonClicked(object sender, EventArgs e)
    {
        IEnumerable<IAccount> accounts = await App.AuthenticationClient.GetAccountsAsync();

        while (accounts.Any())
        {
            await App.AuthenticationClient.RemoveAsync(accounts.First());
            accounts = await App.AuthenticationClient.GetAccountsAsync();
        }

        await Navigation.PopAsync();
    }
}

iOS

Sur iOS, le schéma d’URL personnalisé qui a été inscrit auprès d’Azure Active Directory B2C doit être inscrit dans Info.plist. MSAL s’attend à ce que le schéma d’URL adhère à un modèle spécifique, décrit précédemment dans Inscrire votre application mobile auprès d’Azure Active Directory B2C. La capture d’écran suivante montre le schéma d’URL personnalisé dans Info.plist.

« Inscription d’un schéma d’URL personnalisé sur iOS »

MSAL nécessite également des droits de trousseau sur iOS, inscrits dans Entitilements.plist, comme illustré dans la capture d’écran suivante :

« Définition des droits d’utilisation des applications sur iOS »

Quand Azure Active Directory B2C termine la demande d’autorisation, il redirige vers l’URL de redirection inscrite. Le schéma d’URL personnalisé entraîne le lancement de l’application mobile par iOS et le passage de l’URL en tant que paramètre de lancement, où il est traité par le OpenUrl remplacement de la classe de AppDelegate l’application et retourne le contrôle de l’expérience à MSAL. L’implémentation OpenUrl est illustrée dans l’exemple de code suivant :

using Microsoft.Identity.Client;

namespace TodoAzure.iOS
{
    [Register("AppDelegate")]
    public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate
    {
        ...
        public override bool OpenUrl(UIApplication app, NSUrl url, NSDictionary options)
        {
            AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(url);
            return base.OpenUrl(app, url, options);
        }
    }
}

Android

Sur Android, le schéma d’URL personnalisé qui a été inscrit auprès d’Azure Active Directory B2C doit être inscrit dans le AndroidManifest.xml. MSAL s’attend à ce que le schéma d’URL adhère à un modèle spécifique, décrit précédemment dans Inscrire votre application mobile auprès d’Azure Active Directory B2C. L’exemple suivant montre le schéma d’URL personnalisé dans le AndroidManifest.xml.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.xamarin.adb2cauthorization">
  <uses-sdk android:minSdkVersion="15" />
  <application android:label="ADB2CAuthorization">
    <activity android:name="microsoft.identity.client.BrowserTabActivity">
      <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <!-- example -->
        <!-- <data android:scheme="msalaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" android:host="auth" /> -->
        <data android:scheme="INSERT_URI_SCHEME_HERE" android:host="auth" />
      </intent-filter>
    </activity>"
  </application>
</manifest>

La MainActivity classe doit être modifiée pour fournir l’objet UIParent à l’application pendant l’appel OnCreate . Quand Azure Active Directory B2C termine la demande d’autorisation, il redirige vers le schéma d’URL inscrit à partir du AndroidManifest.xml. Le schéma d’URI inscrit entraîne l’appel d’Android de la OnActivityResult méthode avec l’URL comme paramètre de lancement, où elle est traitée par la SetAuthenticationContinuationEventArgs méthode .

public class MainActivity : FormsAppCompatActivity
{
    protected override void OnCreate(Bundle bundle)
    {
        TabLayoutResource = Resource.Layout.Tabbar;
        ToolbarResource = Resource.Layout.Toolbar;

        base.OnCreate(bundle);

        Forms.Init(this, bundle);
        LoadApplication(new App());
        App.UIParent = this;
    }

    protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
    {
        base.OnActivityResult(requestCode, resultCode, data);
        AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(requestCode, resultCode, data);
    }
}

Plateforme Windows universelle

Aucune configuration supplémentaire n’est nécessaire pour utiliser MSAL sur le plateforme Windows universelle

Exécuter le projet

Exécutez l’application sur un appareil virtuel ou physique. Appuyez sur le bouton Connexion pour ouvrir le navigateur et accéder à une page dans laquelle vous pouvez vous connecter ou créer un compte. Une fois le processus de connexion terminé, vous devez revenir à la page de déconnexion de l’application. La capture d’écran suivante montre l’écran de connexion utilisateur en cours d’exécution sur Android et iOS :

« Écran de connexion Azure ADB2C sur Android et iOS »