Partage via


Configurer les jetons dans Azure Active Directory B2C

Avant de commencer, utilisez le sélecteur Choisir un type de stratégie 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 cet article, vous allez apprendre à configurer la durée de vie et la compatibilité d’un jeton dans Azure Active Directory B2C (Azure AD B2C).

Prérequis

Comportement de durée de vie de jeton

Vous pouvez configurer la durée de vie d’un jeton, à savoir :

  • Durées de vie des jetons d’accès et d’ID (minutes) : durée de vie du jeton du porteur OAuth 2.0 et des jetons d’ID. La valeur par défaut est de 60 minutes (1 heure). La valeur minimale (inclusive) est de 5 minutes. La valeur maximale (inclusive) est de 1 440 minutes (24 heures).
  • Durée de vie du jeton d’actualisation (jours) : période maximale avant laquelle un jeton d’actualisation peut être utilisé pour acquérir un nouveau jeton d’accès si l’étendue offline_access a été accordée à votre application. La valeur par défaut est de 14 jours. La valeur minimale (inclusive) est de 1 jour. La valeur maximale (inclusive) est de 90 jours.
  • Durée de vie de la fenêtre glissante du jeton d’actualisation : type de fenêtre glissante du jeton d’actualisation. Bounded indique que le jeton d’actualisation peut être étendu comme spécifié dans la Durée de vie (jours) . No expiry indique que la durée de vie de la fenêtre glissante du jeton d’actualisation n’expire jamais.
  • Longueur de la durée de vie (jours) : une fois cette période écoulée, l’utilisateur est obligé de s’authentifier de nouveau, quelle que soit la période de validité du dernier jeton d’actualisation acquis par l’application. La valeur doit être supérieure ou égale à la valeur de Durée de vie du jeton d’actualisation.

Le diagramme suivant montre le comportement de durée de vie de la fenêtre glissante du jeton d’actualisation.

Refresh token lifetime

Remarque

Avec les applications monopages qui utilisent le flux de code d’autorisation avec PKCE, la durée de vie du jeton d’actualisation est toujours de 24 heures. Cette limite n’existe pas pour les applications mobiles, les applications de bureau et les applications web. En savoir plus sur les implications pour la sécurité des jetons d’actualisation dans le navigateur.

Configurer la durée de vie des jetons

Pour configurer la durée de vie du jeton de votre flux utilisateur :

  1. Connectez-vous au portail Azure.
  2. Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Annuaires + abonnements.
  3. Choisissez Tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
  4. Sélectionnez Flux utilisateur (stratégies) .
  5. Ouvrez le flux utilisateur que vous avez créé précédemment.
  6. Sélectionner Propriétés.
  7. Sous Durée de vie du jeton, ajustez les propriétés en fonction des besoins de votre application.
  8. Cliquez sur Enregistrer.

configure user flows tokens in Azure portal.

Pour modifier les paramètres de compatibilité de votre jeton, définissez les métadonnées de profil technique de l’émetteur de jeton dans l’extension, ou le fichier de partie de confiance de la stratégie qui doit être affectée. Le profil technique d’émetteur de jeton ressemble à l’exemple suivant :

<ClaimsProviders>
  <ClaimsProvider>
    <DisplayName>Token Issuer</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="JwtIssuer">
        <Metadata>
          <Item Key="token_lifetime_secs">3600</Item>
          <Item Key="id_token_lifetime_secs">3600</Item>
          <Item Key="refresh_token_lifetime_secs">1209600</Item>
          <Item Key="rolling_refresh_token_lifetime_secs">7776000</Item>
          <!--<Item Key="allow_infinite_rolling_refresh_token">true</Item>-->
          <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
          <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
        </Metadata>
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
</ClaimsProviders>

Les valeurs suivantes sont définies dans l’exemple précédent :

  • token_lifetime_secs : durées de vie de jeton d’accès (secondes). La valeur par défaut est 3 600 (1 heure). La valeur minimale est 300 (5 minutes). La valeur maximale est 86 400 (24 heures).
  • id_token_lifetime_secs : durées de vie de jeton d’ID (secondes). La valeur par défaut est 3 600 (1 heure). La valeur minimale est 300 (5 minutes). La valeur maximale est 86 400 (24 heures).
  • refresh_token_lifetime_secs : durée de vie de jeton d’actualisation (secondes). La valeur par défaut est 1 209 600 (14 jours). La valeur minimale est 86 400 (24 heures). La valeur maximale est 7 776 000 (90 jours).
  • rolling_refresh_token_lifetime_secs : durée de vie de la fenêtre glissante du jeton d’actualisation (secondes). La valeur par défaut est 7 776 000 (90 jours). La valeur minimale est 86 400 (24 heures). La valeur maximale est 31 536 000 jours (365 jours). Si vous ne souhaitez pas appliquer une durée de vie de fenêtre glissante, définissez la valeur de allow_infinite_rolling_refresh_token sur true.
  • allow_infinite_rolling_refresh_token : la durée de vie de la fenêtre glissante du jeton d’actualisation n’expire jamais.

Paramètres de conformité de jeton

Vous pouvez configurer la compatibilité du jeton, à savoir :

  • Revendication de l’émetteur (iss) : format de l’émetteur du jeton d’accès et d’ID.
  • Revendication d’objet (obj) : objet principal sur lequel portent les assertions d’informations du jeton, comme l’utilisateur d’une application. Cette valeur est immuable et ne peut pas être réattribuée ou réutilisée. Vous pouvez l’utiliser pour effectuer des vérifications d’autorisation en toute sécurité, comme lorsque le jeton est utilisé pour accéder à une ressource. Par défaut, la revendication de l’objet est remplie avec l’ID d’objet de l’utilisateur dans le répertoire.
  • Revendication représentant le workflow utilisateur : cette revendication identifie le flux utilisateur exécuté. Valeurs possibles : tfp (par défaut) ou acr.

Pour configurer les paramètres de compatibilité de votre flux utilisateur :

  1. Sélectionnez Flux utilisateur (stratégies) .
  2. Ouvrez le flux utilisateur que vous avez créé précédemment.
  3. Sélectionner Propriétés.
  4. Sous Paramètres de compatibilité de jeton, ajustez les propriétés en fonction des besoins de votre application.
  5. Sélectionnez Enregistrer.

Pour modifier les paramètres de compatibilité de votre jeton, définissez les métadonnées de profil technique de l’émetteur de jeton dans l’extension, ou le fichier de partie de confiance de la stratégie qui doit être mise à jour. Le profil technique d’émetteur de jeton ressemble à l’exemple suivant :

<ClaimsProviders>
  <ClaimsProvider>
    <DisplayName>Token Issuer</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="JwtIssuer">
        <Metadata>
          ...
          <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
          <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
        </Metadata>
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
</ClaimsProviders>
  • Revendication de l’émetteur (iss) : la revendication de l’émetteur (iss) est définie avec l’élément de métadonnées IssuanceClaimPattern. Les valeurs possibles sont AuthorityAndTenantGuid et AuthorityWithTfp.

  • Paramétrage de l’ID de stratégie représentant la revendication : les options permettant de définir cette valeur sont TFP (Trust Framework Policy) et ACR (Authentication Context Reference). TFP est la valeur recommandée. Définissez AuthenticationContextReferenceClaimPattern avec la valeur de None.

    Dans l'élément ClaimsSchema, ajoutez l'élément suivant :

    <ClaimType Id="trustFrameworkPolicy">
      <DisplayName>Trust framework policy name</DisplayName>
      <DataType>string</DataType>
    </ClaimType>
    

    Dans votre stratégie de partie de confiance, sous l’élément OutputClaims, ajoutez la revendication de sortie suivante :

    <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp" />
    

    Pour l’option ACR, supprimez l’élément AuthenticationContextReferenceClaimPattern.

  • Revendication de sujet (sub) : cette option est définie par défaut sur ObjectID. Si vous souhaitez que cette option soit définie sur Not Supported, remplacez cette ligne :

    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
    

    par cette ligne :

    <OutputClaim ClaimTypeReferenceId="sub" />
    

Fournir des revendications facultatives à votre application

Les revendications d’application sont des valeurs qui sont retournées à l’application. Mettez à jour votre flux d’utilisateurs pour qu’il contienne les revendications souhaitées.

  1. Sélectionnez Flux utilisateur (stratégies) .
  2. Ouvrez le flux utilisateur que vous avez créé précédemment.
  3. Cliquez sur Revendications de l’application.
  4. Choisissez les revendications et les attributs que vous souhaitez renvoyer à votre application.
  5. Sélectionnez Enregistrer.

Les revendications de sortie du profil technique de la stratégie de partie de confiance sont des valeurs qui sont retournées à une application. L’ajout de revendications de sortie émettra les revendications dans le jeton après un parcours utilisateur réussi et les enverra à l’application. Modifiez l’élément de profil technique dans la section de partie de confiance pour ajouter les revendications souhaitées en tant que revendication de sortie.

  1. Ouvrez votre fichier de stratégie personnalisée. Par exemple SignUpOrSignin.xml.
  2. Recherchez l’élément OutputClaims. Ajoutez l’élément OutputClaim que vous souhaitez inclure dans le jeton.
  3. Définissez les attributs de la revendication de sortie.

L’exemple suivant ajoute la revendication accountBalance. La revendication accountBalance est envoyée à l’application sous forme de solde.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <!--Add the optional claims here-->
      <OutputClaim ClaimTypeReferenceId="accountBalance" DefaultValue="" PartnerClaimType="balance" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

L’élément OutputClaim contient les attributs suivants :

  • ClaimTypeReferenceId : Identificateur d’un type de revendication déjà défini dans la section ClaimsSchema du fichier de stratégie ou d’un fichier de stratégie parent.
  • PartnerClaimType : Vous permet de modifier le nom de la revendication dans le jeton.
  • DefaultValue : Valeur par défaut. Vous pouvez également définir la valeur par défaut sur un programme de résolution de revendications, par exemple l’ID de locataire.
  • AlwaysUseDefaultValue : force l’utilisation de la valeur par défaut.

Durée de vie du code d’autorisation

Lorsque vous utilisez le flux de code d’autorisation OAuth 2.0, l’application peut utiliser le code d’autorisation pour demander un jeton d’accès pour une ressource cible. Les codes d’autorisation ont une durée de vie courte et expirent au bout de 10 minutes. Il n’est pas possible de configurer la durée de vie du code d’autorisation. Assurez-vous que votre application utilise les codes d’autorisation dans un délai de 10 minutes.

Étapes suivantes