Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 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).
Conditions préalables
- Créez un flux d’utilisateurs pour permettre aux utilisateurs de s’inscrire et de se connecter à votre application.
- Inscrire une application web.
- Suivez les étapes de Prise en main des stratégies personnalisées dans Active Directory B2C. Ce tutoriel vous explique comment mettre à jour des fichiers de stratégie personnalisés pour utiliser votre configuration de locataire Azure AD B2C.
- Inscrire une application web.
Comportement de durée de vie de jeton
Vous pouvez configurer la durée de vie des jetons, notamment :
- 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 jetons d’ID. La valeur par défaut est 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 votre application avait reçu l’étendue
offline_access. La valeur par défaut est de 14 jours. Le minimum (inclusif) est un jour. Le maximum est de 90 jours (inclus). -
Durée de vie de la fenêtre glissante du jeton d’actualisation : type de fenêtre glissante du jeton d’actualisation.
Boundedindique que le jeton d’actualisation peut être étendu comme spécifié dans la durée de vie (jours) .No expiryindique que la durée de vie de la fenêtre glissante du jeton d’actualisation n’expire jamais. - Durée de vie (jours) : une fois cette période écoulée, l’utilisateur est obligé de se réauthentifier, quelle que soit la période de validité du jeton d’actualisation le plus récent 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.
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 de sécurité des jetons d’actualisation dans le navigateur.
Configurer la durée de vie des jetons
Pour configurer la durée de vie de votre jeton de flux utilisateur :
- Connectez-vous au portail Azure.
- 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.
- Choisissez tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
- Sélectionnez Flux d’utilisateurs (stratégies).
- Ouvrez le flux utilisateur que vous avez créé précédemment.
- Sélectionnez Propriétés.
- Sous durée de vie du jeton, ajustez les propriétés en fonction des besoins de votre application.
- Cliquez sur 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 affectée. Le profil technique de l’é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 des jetons d’accès (secondes). La valeur par défaut est 3 600 (1 heure). Le minimum est de 300 (5 minutes). Le maximum est de 86 400 (24 heures).
- id_token_lifetime_secs - Durées de vie des jetons d’ID (secondes). La valeur par défaut est 3 600 (1 heure). Le minimum est de 300 (5 minutes). Le maximum est de 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). Le minimum est de 86 400 (24 heures). Le maximum est de 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). Le minimum est de 86 400 (24 heures). Le maximum est de 31 536 000 (365 jours). Si vous ne souhaitez pas appliquer une durée de vie de fenêtre glissante, définissez la valeur sur
allow_infinite_rolling_refresh_tokentrue. - 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 compatibilité des jetons
Vous pouvez configurer la compatibilité des jetons, notamment :
- 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. Il peut être utilisé pour effectuer des vérifications d’autorisation en toute sécurité, par exemple 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 flux utilisateur : cette revendication identifie le flux utilisateur qui a été exécuté. Valeurs possibles :
tfp(par défaut) ouacr.
Pour configurer vos paramètres de compatibilité de flux utilisateur :
- Sélectionnez Flux d’utilisateurs (stratégies).
- Ouvrez le flux utilisateur que vous avez créé précédemment.
- Sélectionnez Propriétés.
- Sous Paramètres de compatibilité des jetons, ajustez les propriétés en fonction des besoins de votre application.
- Cliquez sur Enregistrer.
Pour modifier les paramètres de compatibilité de votre jeton, vous 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 que vous souhaitez mettre à jour. Le profil technique de l’é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 applicables sont
AuthorityAndTenantGuidetAuthorityWithTfp.Définition de la revendication représentant l’ID de stratégie : les options de définition de cette valeur sont
TFP(stratégie d’infrastructure de confiance) etACR(référence du contexte d’authentification).TFPest la valeur recommandée. Définissez AuthenticationContextReferenceClaimPattern avec la valeur deNone.Dans l’élément ClaimsSchema , ajoutez cet élément :
<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 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 utilisateur pour contenir les revendications souhaitées.
- Sélectionnez Flux d’utilisateurs (stratégies).
- Ouvrez le flux utilisateur que vous avez créé précédemment.
- Sélectionnez paramètres d’application.
- Choisissez les revendications et les attributs que vous souhaitez renvoyer à votre application.
- Cliquez sur 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.
- Ouvrez votre fichier de stratégie personnalisé. Par exemple, SignUpOrSignin.xml.
- Recherchez l’élément OutputClaims. Ajoutez l'OutputClaim que vous souhaitez inclure dans le jeton.
- Définissez les attributs de la revendication de sortie.
L’exemple suivant ajoute la accountBalance revendication. 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 du 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 revendication, tel que 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 sont de courte durée qui expirent après environ 10 minutes. La durée de vie du code d’autorisation ne peut pas être configurée. Assurez-vous que votre application échange les codes d’autorisation dans les 10 minutes.
Contenu connexe
- En savoir plus sur la façon de demander des jetons d’accès.
- Découvrez comment créer la résilience par le biais des meilleures pratiques pour les développeurs.