Partager via


Configurer un flux d’informations d’identification de mot de passe du propriétaire de la ressource dans Azure Active Directory B2C

Important

À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.

Avant de commencer, utilisez le sélecteur Choisir un type de stratégie en haut de cette page pour choisir le type de stratégie que vous configurez. Azure Active Directory B2C offre deux possibilités pour définir la façon dont les utilisateurs interagissent avec vos applications : via des flux utilisateurs prédéfinis ou via des stratégies personnalisées entièrement configurables. La procédure donnée dans cet article est différente pour chaque méthode.

Dans Azure Active Directory B2C (Azure AD B2C), le flux d’informations d’identification de mot de passe du propriétaire de la ressource (ROPC) est un flux d’authentification standard OAuth. Dans ce flux, une application, également appelée partie de confiance, échange des informations d’identification valides pour les jetons. Les informations d’identification incluent un ID d’utilisateur et un mot de passe. Les jetons retournés sont un jeton d’ID, un jeton d’accès et un jeton d’actualisation.

Avertissement

Nous vous recommandons de ne pas utiliser le flux ROPC. 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.

Notes relatives au flux ROPC

Dans Azure Active Directory B2C (Azure AD B2C), les options suivantes sont prises en charge :

  • Native Client : l’interaction utilisateur pendant l’authentification se produit lorsque le code s’exécute sur un appareil côté utilisateur. L’appareil peut être une application mobile qui s’exécute dans un système d’exploitation natif, tel qu’Android et iOS.
  • Flux client public : seules les informations d’identification de l’utilisateur, collectées par une application, sont envoyées dans l’appel d’API. Les identifiants de l'application ne sont pas envoyés.
  • Ajouter de nouvelles revendications : le contenu du jeton d’ID peut être modifié pour ajouter de nouvelles revendications.

Les flux suivants ne sont pas pris en charge :

  • Serveur à serveur : le système de protection des identités a besoin d’une adresse IP fiable collectée auprès de l’appelant (le client natif) dans le cadre de l’interaction. Dans un appel d’API côté serveur, seule l’adresse IP du serveur est utilisée. Si un seuil dynamique d’authentifications ayant échoué est dépassé, le système de protection des identités peut identifier une adresse IP répétée en tant qu’attaquant.
  • Flux client confidentiel : l’ID client de l’application est validé, mais la clé secrète de l’application n’est pas validée.

Lorsque vous utilisez le flux ROPC, tenez compte des limitations suivantes :

  • ROPC ne fonctionne pas en cas d’interruption du flux d’authentification nécessitant une interaction utilisateur. Par exemple, lorsqu’un mot de passe expire ou doit être modifié, l’authentification multifacteur est requise, ou lorsque d’autres informations doivent être collectées lors de la connexion (par exemple, le consentement de l’utilisateur).
  • ROPC prend uniquement en charge les comptes locaux. Les utilisateurs ne peuvent pas se connecter avec des fournisseurs d’identité fédérés tels que Microsoft, Google+, X, AD-FS ou Facebook.
  • La gestion des sessions, y compris me garder connecté (KMSI), n’est pas applicable.

Inscrire une application

Pour enregistrer une application dans votre locataire Azure AD B2C, vous pouvez utiliser notre nouvelle expérience unifiée d’enregistrement d’applications ou notre expérience d’applications héritées. En savoir plus sur la nouvelle expérience.

  1. Connectez-vous au portail Azure.
  2. Assurez-vous d'utiliser le répertoire où réside votre instance Azure AD B2C :
    1. Sélectionnez l’icône Répertoires + abonnements dans la barre d’outils du portail.
    2. Sur la page Paramètres du portail | Répertoires + abonnements, recherchez votre répertoire AD B2C Azure dans la liste Nom de répertoire, puis sélectionnez Basculer.
  3. Dans le portail Azure, recherchez et sélectionnez Azure AD B2C
  4. Sélectionnez Inscriptions d'applications, puis sélectionnez Nouvelle inscription.
  5. Entrez un nom pour l’application. Par exemple, ROPC_Auth_app.
  6. Laissez les autres valeurs comme elles le sont, puis sélectionnez Inscrire.
  7. Enregistrez l’ID d’application (client) à utiliser dans une étape ultérieure.
  8. Sous Gérer, sélectionnez Authentification.
  9. Sélectionnez Essayer la nouvelle expérience (le cas échéant).
  10. Sous Paramètres avancés et section Activer les flux mobiles et de bureau suivants, sélectionnez Oui pour traiter l’application en tant que client public. Ce paramètre est requis pour le flux ROPC.
  11. Cliquez sur Enregistrer.
  12. Dans le menu de gauche, sélectionnez Manifeste pour ouvrir l’éditeur de manifeste.
  13. Définissez l’attribut oauth2AllowImplicitFlow sur true. Si l’attribut n’existe pas, ajoutez-le :
    "oauth2AllowImplicitFlow": true,
    
  14. Cliquez sur Enregistrer.

Créer un parcours utilisateur pour le propriétaire de ressources

  1. Connectez-vous au portail Azure en tant qu’administrateur de flux d’utilisateur ID externe de votre locataire Azure AD B2C.
  2. Si vous avez accès à plusieurs tenants (locataires), sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre tenant Azure AD B2C à partir du menu Annuaires + abonnements.
  3. Dans le portail Azure, recherchez et sélectionnez Azure AD B2C.
  4. Sélectionnez Flux utilisateur, puis Nouveau flux d’utilisateur.
  5. Sélectionnez Se connecter à l’aide des informations d’identification de mot de passe du propriétaire de la ressource (ROPC).
  6. Sous Version, vérifiez que l’aperçu est sélectionné, puis sélectionnez Créer.
  7. Fournissez un nom pour le flux d’utilisateur, tel que ROPC_Auth.
  8. Sous Revendications d’application, sélectionnez Afficher plus.
  9. Sélectionnez les revendications d’application dont vous avez besoin pour votre application, telles que le nom d’affichage, l’adresse e-mail et le fournisseur d’identité.
  10. Sélectionnez OK, puis sélectionnez Créer.

Prérequis

Si vous ne l’avez pas fait, découvrez comment utiliser le pack de démarrage de stratégie personnalisé dans Prise en main des stratégies personnalisées dans Active Directory B2C.

Créer une politique de propriétaire de ressource

  1. Ouvrez le fichier TrustFrameworkExtensions.xml .

  2. Sous l’élément BuildingBlocks , recherchez l’élément ClaimsSchema , puis ajoutez les types de revendications suivants :

    <ClaimsSchema>
      <ClaimType Id="logonIdentifier">
        <DisplayName>User name or email address that the user can use to sign in</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="resource">
        <DisplayName>The resource parameter passes to the ROPC endpoint</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="refreshTokenIssuedOnDateTime">
        <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="refreshTokensValidFromDateTime">
        <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
    </ClaimsSchema>
    
  3. Après ClaimsSchema, ajoutez un élément ClaimsTransformations et ses éléments enfants à l’élément BuildingBlocks :

    <ClaimsTransformations>
      <ClaimsTransformation Id="CreateSubjectClaimFromObjectID" TransformationMethod="CreateStringClaim">
        <InputParameters>
          <InputParameter Id="value" DataType="string" Value="Not supported currently. Use oid claim." />
        </InputParameters>
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="sub" TransformationClaimType="createdClaim" />
        </OutputClaims>
      </ClaimsTransformation>
    
      <ClaimsTransformation Id="AssertRefreshTokenIssuedLaterThanValidFromDate" TransformationMethod="AssertDateTimeIsGreaterThan">
        <InputClaims>
          <InputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" TransformationClaimType="leftOperand" />
          <InputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" TransformationClaimType="rightOperand" />
        </InputClaims>
        <InputParameters>
          <InputParameter Id="AssertIfEqualTo" DataType="boolean" Value="false" />
          <InputParameter Id="AssertIfRightOperandIsNotPresent" DataType="boolean" Value="true" />
        </InputParameters>
      </ClaimsTransformation>
    </ClaimsTransformations>
    
  4. Recherchez l’élément ClaimsProvider qui a un DisplayName de Local Account SignIn et ajoutez le profil technique suivant :

    <TechnicalProfile Id="ResourceOwnerPasswordCredentials-OAUTH2">
      <DisplayName>Local Account SignIn</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item>
        <Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>
        <Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item>
        <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
        <Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/</Item>
        <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
        <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
        <Item Key="response_types">id_token</Item>
        <Item Key="response_mode">query</Item>
        <Item Key="scope">email openid</Item>
        <Item Key="grant_type">password</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="logonIdentifier" PartnerClaimType="username" Required="true" DefaultValue="{OIDC:Username}"/>
        <InputClaim ClaimTypeReferenceId="password" Required="true" DefaultValue="{OIDC:Password}" />
        <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
        <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
        <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
        <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppId" />
        <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppId" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
        <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
    

    Remplacez DefaultValue de client_id par l’ID d’application de l’application ProxyIdentityExperienceFramework que vous avez créée dans le didacticiel requis. Ensuite, remplacez DefaultValue de resource_id par l’ID de l'application de l’ApplicationIdentityExperienceFramework que vous avez créé dans le didacticiel préalable.

  5. Ajoutez les éléments ClaimsProvider suivants avec leurs profils techniques à l’élément ClaimsProviders :

    <ClaimsProvider>
      <DisplayName>Azure Active Directory</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="AAD-UserReadUsingObjectId-CheckRefreshTokenDate">
          <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="objectId" Required="true" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="AssertRefreshTokenIssuedLaterThanValidFromDate" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
          </OutputClaimsTransformations>
          <IncludeTechnicalProfile ReferenceId="AAD-Common" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
    <ClaimsProvider>
      <DisplayName>Session Management</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="SM-RefreshTokenReadAndSetup">
          <DisplayName>Trustframework Policy Engine Refresh Token Setup Technical Profile</DisplayName>
          <Protocol Name="None" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" />
          </OutputClaims>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="JwtIssuer">
          <Metadata>
            <!-- Point to the redeem refresh token user journey-->
            <Item Key="RefreshTokenUserJourneyId">ResourceOwnerPasswordCredentials-RedeemRefreshToken</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  6. Ajoutez un élément UserJourneys et ses éléments enfants à l’élément TrustFrameworkPolicy :

    <UserJourney Id="ResourceOwnerPasswordCredentials">
      <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="ResourceOwnerFlow" TechnicalProfileReferenceId="ResourceOwnerPasswordCredentials-OAUTH2" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
    </UserJourney>
    <UserJourney Id="ResourceOwnerPasswordCredentials-RedeemRefreshToken">
      <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="RefreshTokenSetupExchange" TechnicalProfileReferenceId="SM-RefreshTokenReadAndSetup" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="CheckRefreshTokenDateFromAadExchange" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId-CheckRefreshTokenDate" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
    </UserJourney>
    
  7. Dans la page Stratégies personnalisées de votre locataire Azure AD B2C, sélectionnez Charger une stratégie.

  8. Activez Remplacer la stratégie si elle existe, puis recherchez et sélectionnez le fichier TrustFrameworkExtensions.xml.

  9. Sélectionnez Téléverser.

Créer un fichier de tiers de confiance

Ensuite, mettez à jour le fichier de tiers de confiance qui lance l'expérience utilisateur que vous avez créée :

  1. Effectuez une copie de SignUpOrSignin.xml fichier dans votre répertoire de travail et renommez-le enROPC_Auth.xml.

  2. Ouvrez le nouveau fichier et remplacez la valeur de l’attribut PolicyId pour TrustFrameworkPolicy par une valeur unique. L’ID de stratégie est le nom de votre stratégie. Par exemple, B2C_1A_ROPC_Auth.

  3. Remplacez la valeur de l’attribut ReferenceId dans DefaultUserJourneyResourceOwnerPasswordCredentialspar .

  4. Modifiez l’élément OutputClaims pour qu’il contienne uniquement les revendications suivantes :

    <OutputClaim ClaimTypeReferenceId="sub" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="displayName" DefaultValue="" />
    <OutputClaim ClaimTypeReferenceId="givenName" DefaultValue="" />
    <OutputClaim ClaimTypeReferenceId="surname" DefaultValue="" />
    
  5. Dans la page Stratégies personnalisées de votre locataire Azure AD B2C, sélectionnez Charger une stratégie.

  6. Activez Remplacer la stratégie si elle existe, puis recherchez et sélectionnez le fichier ROPC_Auth.xml.

  7. Sélectionnez Téléverser.

Tester le flux ROPC

Utilisez votre application de développement d’API préférée pour générer un appel d’API et passez en revue la réponse pour déboguer votre stratégie. Construisez un appel comme cet exemple avec les informations suivantes comme corps de la requête POST :

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

  • Remplacez <tenant-name> par le nom de votre locataire Azure AD B2C.
  • Remplacez B2C_1A_ROPC_Auth par le nom complet de votre stratégie d’informations d’identification de mot de passe du propriétaire de ressource.
Clé Valeur
nom d'utilisateur user-account
mot de passe password1
type d'autorisation mot de passe
portée openid application-id accès hors ligne
client_id application-id
type_de_réponse id_token du jeton
  • Remplacez user-account par le nom d’un compte d’utilisateur dans votre instance.
  • Remplacez password1 par le mot de passe du compte d’utilisateur.
  • Remplacez application-id par l’ID d'application associé à l'enregistrement ROPC_Auth_app.
  • Offline_access est facultatif si vous souhaitez recevoir un jeton d’actualisation.

La requête POST réelle ressemble à l’exemple suivant :

POST /<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

username=contosouser.outlook.com.ws&password=Passxword1&grant_type=password&scope=openid+00001111-aaaa-2222-bbbb-3333cccc4444+offline_access&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&response_type=token+id_token

Une réponse réussie avec accès hors connexion ressemble à l’exemple suivant :

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki...",
    "token_type": "Bearer",
    "expires_in": "3600",
    "refresh_token": "eyJraWQiOiJacW9pQlp2TW5pYVc2MUY0TnlfR3REVk1EVFBLbUJLb0FUcWQ1ZWFja1hBIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6Ij...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki..."
}

Échanger un jeton d’actualisation

Construisez un appel POST comme celui présenté ici. Utilisez les informations du tableau suivant comme corps de la requête :

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

  • Remplacez <tenant-name> par le nom de votre locataire Azure AD B2C.
  • Remplacez B2C_1A_ROPC_Auth par le nom complet de votre stratégie d’informations d’identification de mot de passe du propriétaire de ressource.
Clé Valeur
type d'autorisation jeton_de_actualisation
type_de_réponse Jeton d'identification (id_token)
client_id application-id
ressource application-id
jeton_de_actualisation refresh-token
  • Remplacez application-id par l’ID d'application associé à l'enregistrement ROPC_Auth_app.
  • Remplacez refresh-token par le refresh_token qui a été renvoyé dans la réponse précédente.

Une réponse réussie ressemble à l’exemple suivant :

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndhT...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQn...",
    "token_type": "Bearer",
    "not_before": 1533672990,
    "expires_in": 3600,
    "expires_on": 1533676590,
    "resource": "bef2222d56-552f-4a5b-b90a-1988a7d634c3",
    "id_token_expires_in": 3600,
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiI1MTZmYzA2NS1mZjM2LTRiOTMtYWE1YS1kNmVlZGE3Y2JhYzgiLCJzdWIiOm51bGwsIm5hbWUiOiJEYXZpZE11IiwicHJlZmVycmVkX3VzZXJuYW1lIjpudWxsLCJpZHAiOiJMb2NhbEFjY291bnQifQ",
    "refresh_token": "eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMCIsInppcCI6IkRlZmxhdGUiLCJzZXIiOiIxLjAi...",
    "refresh_token_expires_in": 1209600
}

Résolution des problèmes

L’application fournie n’est pas configurée pour autoriser le flux implicite « OAuth »

  • Symptôme : vous exécutez le flux ROPC et recevez le message suivant : AADB2C90057 : l’application fournie n’est pas configurée pour autoriser le flux implicite « OAuth ».
  • Causes possibles : le flux implicite n’est pas autorisé pour votre application.
  • Résolution : lors de la création de votre inscription d’application dans Azure AD B2C, vous devez modifier manuellement le manifeste de l’application et définir la valeur de la oauth2AllowImplicitFlow propriété truesur . Après avoir configuré la oauth2AllowImplicitFlow propriété, la modification peut prendre quelques minutes (généralement pas plus de cinq) pour que la modification prenne effet.

Utiliser un Kit de développement logiciel (SDK) natif ou un App-Auth

Azure AD B2C répond aux normes OAuth 2.0 pour les informations d’identification de mot de passe du propriétaire des ressources client publiques et doit être compatible avec la plupart des kits SDK clients. Pour plus d’informations, consultez le Kit de développement logiciel (SDK) d’application native pour OAuth 2.0 et OpenID Connect qui implémentent les meilleures pratiques modernes.