Utiliser msAL Python pour utiliser Azure AD B2C

Vous pouvez utiliser MSAL Python pour connecter des utilisateurs avec des identités sociales, acquérir des jetons et personnaliser l’expérience de connexion à l’aide de Azure AD B2C.

Azure AD B2C repose sur la notion de flux d’utilisateurs (anciennement appelés stratégies). Dans MSAL Python, la spécification d’un flux utilisateur se traduit par la fourniture d’une autorité.

• Lorsque vous créez une instance de l’application cliente, vous devez spécifier le flux utilisateur dans le paramètre d’autorité sous la forme https://{tenant_name}.b2clogin.com/{tenant_name}.onmicrosoft.com/{user_flow}. Et ensuite, chaque acquire_token_by_xyz(...) habituel fonctionnerait avec ce flux utilisateur. Il n’existe aucune différence de surface d’API entre les scénarios B2C et non B2C. Il suffit d’échanger un autre ensemble de configuration, et le même exemple d’application web fonctionne pour les scénarios non B2C et B2C.
• Certains flux utilisateur, tels que modifier le flux utilisateur du profil ou réinitialiser le flux utilisateur de mot de passe, sont essentiellement personnalisés. Vous pouvez obtenir une URL pour ces pages en créant un PublicClientApplication dont l’autorité contient ce {user_flow}, puis en appelant get_authorization_request_url(...). (Dans notre exemple d’application web, nous fournissons même un assistance de niveau supérieur pour eux.)

Vous trouverez plus d’informations sur ce résumé ci-dessous.

Autorité pour un locataire B2C et un flux utilisateur

L’autorité de certification à utiliser est https://{tenant_name}.b2clogin.com/{tenant_name}.onmicrosoft.com/{user_flow}, où :

• tenant_name est le nom du locataire Azure AD B2C, tel que « contoso »
• user_flow est le nom du flux d’utilisateur à appliquer (par exemple, vous pouvez avoir « b2c_1_susi » pour la connexion/l’inscription).

Lors de la création de l’application, vous devez fournir, comme d’habitude, l’autorité, générée comme ci-dessus

app = msal.PublicClientApplication(  # Or ConfidentialClientApplication(...)
    "your_client_id",
    authority="https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_susi",
    ...)

Acquisition d’un jeton

L’acquisition d’un jeton pour une API protégée par Azure AD B2C, en se basant sur le flux utilisateur déjà fourni dans l’autorité, est exactement la même que ce que vous feriez dans un scénario non B2C. C'est pourquoi notre exemple d'application web Python non B2C sert également d'exemple d'application web B2C. Son fichier app.py principal fonctionne à la fois sur les scénarios non B2C et B2C sans aucune modification.

app.acquire_token_by_xyz(...)  # Same as in non-B2C scenarios

Il n’est pas nécessaire de filtrer les comptes par flux utilisateur, tant que vous suivez un modèle de « créer une application MSAL différente pour différents flux d’utilisateurs » (car le flux utilisateur B2C est conçu pour se comporter comme une autorité isolée). Dans la pratique, vous réutiliserez toujours la même application MSAL et son cache de jetons pour le flux utilisateur SignIn, et créez uniquement une application MSAL unique lors de l’appel de flux utilisateur EditProfile ou ResetPassword, dont le jeton retourné (le cas échéant) ne serait pas utile de toute façon.

Exemple de flux utilisateur EditProfile et ResetPassword

Les flux utilisateur EditProfile et ResetPassword sont les suivants :

• moins axé sur l’acquisition de jetons. Cela peut ne pas être évident, mais c’est parce que actuellement les jetons émis par un flux utilisateur B2C ne sont pas nécessairement compatibles avec les jetons émis par un autre flux utilisateur B2C. Néanmoins, le modèle plus sûr consiste à organiser votre application web pour ne pas partager ces jetons.
• en savoir plus sur une expérience utilisateur personnalisée. Imaginez dans une ancienne application web scolaire (même en dehors du contexte de MSAL ou B2C), comment fourniriez-vous une expérience de modification de profil personnalisée ? Vous devez inclure un lien dans la barre de navigation de votre application web, pointant vers cette page personnalisée.

Notre exemple d’application web B2C est exactement organisé de cette façon pour masquer toutes les décisions sous-jacentes. Vous devez simplement mettre à jour votre modèle HTML pour inclure un nouveau lien vers, par exemple, la page Modifier le profil.

<a href='{{_build_auth_url(authority=config["B2C_PROFILE_AUTHORITY"])}}'>Edit Profile</a>

Informations d’identification par mot de passe du propriétaire de la ressource (ROPC) avec B2C

Il n’existe aucune différence d’API entre un scénario B2C et non B2C. Le contenu suivant sert de mini-didacticiel.

• Dans votre annuaire Azure AD B2C, créez un nouveau flux d’utilisateur et sélectionnez Se connecter avec ROPC. Cela active le flux utilisateur ROPC pour votre locataire. Pour plus d’informations, consultez Configurer le flux d’informations d’identification du mot de passe du propriétaire de la ressource .
• Après avoir créé l’instance MSAL avec l’autorité incluant le flux utilisateur ROPC, acquire_token_by_username_password(...) fonctionnera comme d’habitude.
• Limitations : cela fonctionne uniquement pour les comptes locaux (où vous vous inscrivez auprès de B2C à l’aide d’un e-mail ou d’un nom d’utilisateur). Ce flux ne fonctionne pas si vous effectuez une fédération avec l’un des IdP pris en charge par B2C (Facebook, Google, etc.).

Microsoft décourage l’utilisation de l’octroi d’informations d’identification de mot de passe du propriétaire de la ressource. Dans la plupart des scénarios, des alternatives plus sécurisées sont disponibles et recommandées. Ce flux nécessite un degré de confiance très élevé dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux. Utilisez ce flux uniquement lorsqu’aucun autre flux plus sécurisé n’est viable. Pour en savoir plus, consultez les instructions relatives au nom d’utilisateur et au mot de passe .

Mise en cache avec B2C dans MSAL Python

Problème connu

Le modèle d’utilisation du cache de jetons de MSAL Python commence par interroger tous les comptes existants via get_accounts(...), qui prend en charge un paramètre username comme filtre. Ces données de nom d’utilisateur proviennent d’une preferred_username déclaration dans le jeton d’identification.

Par défaut, cette revendication est manquante dans la plupart des scénarios AZURE AD B2C.

La conséquence pour le client est que, lors de l’affichage des comptes, leur champ de nom d’utilisateur serait vide. Cela peut ne pas vous déranger, si vous utilisez le flux de code d’authentification dans votre application web et que vous ne traitez qu’un seul compte par utilisateur. Mais si vous utilisez le flux ROPC et que vous sentez que vous connaissez déjà le nom d’utilisateur de l’utilisateur final, accounts = app.get_accounts(username="john.doe@contoso.com") vous donnez toujours un résultat vide, car "john.doe@contoso.com" ne correspond ""pas.

La solution de contournement consiste à personnaliser votre flux utilisateur B2C afin de renseigner et de renvoyer une claim preferred_username, ou simplement à appeler votre app.get_accounts() sans paramètre de nom d’utilisateur précis.

Échantillons