Partager via


Gérer l’accès des utilisateurs 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.

Cet article explique comment gérer l’accès des utilisateurs à vos applications à l’aide d’Azure Active Directory B2C (Azure AD B2C). La gestion des accès dans votre application comprend :

  • Identifier les mineurs et contrôler l’accès des utilisateurs à votre application.
  • Exiger le consentement parental pour que les mineurs puissent utiliser vos applications.
  • Collecte de données sur la naissance et le pays/la région auprès des utilisateurs.
  • Capture d’un accord de conditions d’utilisation et blocage de l’accès.

Remarque

Dans Active Directory B2C, les stratégies personnalisées sont principalement conçues pour gérer des scénarios complexes. Pour la plupart des scénarios, nous vous recommandons de recourir à des flux d’utilisateurs intégrés. Si vous ne l’avez pas fait, découvrez le Pack de démarrage de stratégie personnalisée dans Prise en main des stratégies personnalisées dans Active Directory B2C.

Contrôler l’accès mineur

Les applications et les organisations peuvent décider d’empêcher les mineurs d’utiliser des applications et des services qui ne sont pas destinés à ce public. Alternativement, les applications et les organisations peuvent décider d’accepter des mineurs et de gérer par la suite le consentement parental, et d’offrir des expériences autorisées pour les mineurs, comme dicté par les règles commerciales et autorisé par la réglementation.

Si un utilisateur est identifié comme mineur, vous pouvez définir le flux d’utilisateurs dans Azure AD B2C sur l’une des trois options suivantes :

  • Renvoyer un id_token JWT signé à l’application : l’utilisateur est inscrit dans l’annuaire et un jeton est renvoyé à l’application. L’application se poursuit ensuite en appliquant des règles métier. Par exemple, la demande peut suivre un processus de consentement parental. Pour utiliser cette méthode, choisissez de recevoir les réclamations ageGroup et consentProvidedForMinor à partir de l’application.

  • Envoyer un jeton JSON non signé à l’application : Azure AD B2C informe l’application que l’utilisateur est mineur et fournit l’état du consentement parental de l’utilisateur. L’application se poursuit ensuite en appliquant des règles métier. Un jeton JSON ne permet pas de s’authentifier correctement auprès de l’application. L’application doit traiter l’utilisateur non authentifié conformément aux revendications incluses dans le jeton JSON, qui peuvent inclure le nom, l’adresse e-mail, le groupe d’âge et consentProvidedForMinor.

  • Bloquer l’utilisateur : si un utilisateur est mineur et que le consentement parental n’a pas été fourni, Azure AD B2C peut informer l’utilisateur qu’il est bloqué. Aucun jeton n’est émis, l’accès est bloqué et le compte utilisateur n’est pas créé lors d’un parcours d’inscription. Pour mettre en œuvre cette notification, vous devez fournir une page de contenu HTML/CSS appropriée pour informer l’utilisateur et présenter les options appropriées. Aucune autre action n’est requise pour la demande de nouvelles inscriptions.

Selon la réglementation d’application, le consentement parental peut devoir être accordé par un utilisateur dont la qualité adulte est vérifiée. Azure AD B2C ne fournit pas d’expérience permettant de vérifier l’âge d’une personne, puis de permettre à un adulte vérifié d’accorder un consentement parental à un mineur. Cette expérience doit être fournie par l’application ou un autre fournisseur de services.

Voici un exemple de flux d’utilisateurs pour recueillir le consentement parental :

  1. Une opération d’API Microsoft Graph identifie l’utilisateur en tant que mineur et renvoie les données utilisateur à l’application sous la forme d’un jeton JSON non signé.

  2. L’application traite le jeton JSON et montre un écran au mineur, l’informant que le consentement parental est requis et demandant le consentement d’un parent en ligne.

  3. Azure AD B2C affiche un parcours de connexion que l’utilisateur peut suivre pour se connecter normalement. Il émet un jeton à l’application qui doit inclure legalAgeGroupClassification = "minorWithParentalConsent". L’application recueille l’adresse e-mail du parent et vérifie que le parent est majeur. Pour ce faire, il utilise une source fiable, telle qu’un bureau d’identification national/régional, une vérification de licence ou une preuve de carte de crédit. Si la vérification réussit, l’application invite le mineur à se connecter à l’aide du flux d’utilisateurs Azure AD B2C. Si le consentement est refusé (par exemple, si legalAgeGroupClassification = « minorWithoutParentalConsent »), Azure AD B2C retourne un jeton JSON (et non une connexion) à l’application pour redémarrer le processus de consentement. Il est éventuellement possible de personnaliser le flux d’utilisateurs afin qu’un mineur ou un adulte puisse retrouver l’accès au compte d’un mineur en envoyant un code d’inscription à l’adresse e-mail du mineur ou à l’adresse e-mail de l’adulte enregistrée.

  4. L’application offre au mineur la possibilité de révoquer son consentement.

  5. Lorsque le mineur ou l’adulte révoque son consentement, l’API Microsoft Graph peut être utilisée pour remplacer consentProvidedForMinor par denied. Alternativement, l’application peut choisir de supprimer un mineur dont le consentement a été révoqué. Il est éventuellement possible de personnaliser le flux d’utilisateurs afin que le mineur authentifié (ou le parent qui utilise le compte du mineur) puisse révoquer son consentement. Azure AD B2C enregistre consentProvidedForMinor comme refusé.

Pour plus d’informations sur legalAgeGroupClassification, consentProvidedForMinor et ageGroup, consultez Type de ressource utilisateur. Pour plus d’informations sur les attributs personnalisés, consultez Utiliser des attributs personnalisés pour collecter des informations sur vos consommateurs. Lorsque vous adressez des attributs étendus à l’aide de l’API Microsoft Graph, vous devez utiliser la version longue de l’attribut, par exemple extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth : 2011-01-01T00:00:00Z.

Recueillir des données sur la date de naissance et le pays/la région

Les applications peuvent s’appuyer sur Azure AD B2C pour collecter la date de naissance et les informations de pays/région de tous les utilisateurs lors de l’inscription. Si ces informations n’existent pas déjà, l’application peut les demander à l’utilisateur lors du prochain parcours d’authentification (connexion). Les utilisateurs ne peuvent pas continuer sans fournir leur date de naissance et leurs informations sur le pays/la région. Azure AD B2C utilise ces informations pour déterminer si la personne est considérée comme mineure selon les normes réglementaires de ce pays/région.

Un flux d’utilisateurs personnalisé peut collecter des informations sur la date de naissance et le pays/la région et utiliser la transformation des revendications Azure AD B2C pour déterminer le groupe d’âge et conserver le résultat (ou conserver directement les informations sur la date de naissance et le pays/la région) dans l’annuaire.

Les étapes suivantes montrent la logique utilisée pour calculer ageGroup à partir de la date de naissance de l’utilisateur :

  1. Essayez de trouver le pays/la région par le code du pays/de la région dans la liste. Si le pays/la région est introuvable, revenez à Par défaut.

  2. Si le nœud MinorConsent est présent dans l’élément country/region :

    a) Calculez la date à laquelle l’utilisateur doit être né pour être considéré comme un adulte. Par exemple, si la date actuelle est le 14 mars 2015 et que MinorConsent est 18 ans, la date de naissance ne doit pas être postérieure au 14 mars 2000.

    b. Comparez la date minimale de naissance avec la date de naissance réelle. Si la date de naissance minimale est antérieure à la date de naissance de l’utilisateur, le calcul renvoie Mineur comme calcul du groupe d’âge.

  3. Si le nœud MinorNoConsentRequired est présent dans l’élément country/region, répétez les étapes 2a et 2b à l’aide de la valeur de MinorNoConsentRequired. La sortie de 2b renvoie MinorNoConsentRequired si la date de naissance minimale est antérieure à la date de naissance de l’utilisateur.

  4. Si aucun des calculs ne renvoie true, le calcul renvoie Adulte.

Si une application a collecté de manière fiable des données de date de naissance ou de pays/région par d’autres méthodes, l’application peut utiliser l’API Graph pour mettre à jour l’enregistrement de l’utilisateur avec ces informations. Par exemple:

  • Si l’on sait qu’un utilisateur est un adulte, mettez à jour l’attribut d’annuaire ageGroup avec la valeur Adult.
  • Si l’on sait qu’un utilisateur est mineur, mettez à jour l’attribut d’annuaire ageGroup avec la valeur Minor et définissez consentProvidedForMinor, le cas échéant.

Règles de calcul mineures

Le contrôle de l’âge implique deux valeurs d’âge : l’âge auquel une personne n’est plus considérée comme mineure et l’âge auquel un mineur doit avoir le consentement parental. Le tableau suivant répertorie les règles d’âge utilisées pour définir un mineur et un mineur nécessitant un consentement.

Pays/région Nom du pays/de la région Âge du consentement des mineurs Âge mineur
Par défaut Aucun Aucun 18
Æ Émirats arabes unis Aucun Vingt-et-un
À Autriche 14 18
ÊTRE Belgique 14 18
BG Bulgarie 16 18
BH Bahreïn Aucun Vingt-et-un
CM Cameroun Aucun Vingt-et-un
CY Chypre 16 18
CZ République tchèque 16 18
Allemagne Allemagne 16 18
DK Danemark 16 18
EE Estonie 16 18
EG Égypte Aucun Vingt-et-un
ES Espagne 13 18
FR France 16 18
Go Royaume-Uni 13 18
GR Grèce 16 18
RH Croatie 16 18
HU Hongrie 16 18
Internet Explorer Irlande 13 18
TI Italie 16 18
KR Corée, République de 14 18
LT Lituanie 16 18
LU Luxembourg 16 18
LV Lettonie 16 18
MT Malte 16 18
N/D Namibie Aucun Vingt-et-un
NL Pays-Bas 16 18
PL Pologne 13 18
PT Portugal 16 18
RO Roumanie 16 18
SE Suède 13 18
SG Singapour Aucun Vingt-et-un
Système International Slovénie 16 18
SK Slovaquie 16 18
TD Tchad Aucun Vingt-et-un
IÈME Thaïlande Aucun 20
TW Taïwan Aucun 20
États-Unis États-Unis 13 18

Capturer l’accord sur les conditions d’utilisation

Lorsque vous développez votre application, vous enregistrez généralement l’acceptation des conditions d’utilisation par les utilisateurs dans leurs applications, sans ou avec une participation mineure de l’annuaire des utilisateurs. Toutefois, il est possible d’utiliser un flux d’utilisateurs Azure AD B2C pour recueillir l’acceptation des conditions d’utilisation par un utilisateur, restreindre l’accès si l’acceptation n’est pas accordée et imposer l’acceptation des modifications futures des conditions d’utilisation, en fonction de la date de la dernière acceptation et de la date de la dernière version des conditions d’utilisation.

Les conditions d’utilisation peuvent également inclure le « consentement au partage des données avec des tiers ». En fonction des réglementations locales et des règles commerciales, vous pouvez recueillir l’acceptation des deux conditions combinées par un utilisateur, ou vous pouvez autoriser l’utilisateur à accepter une condition et pas l’autre.

Les étapes suivantes décrivent comment vous pouvez gérer les conditions d’utilisation :

  1. Enregistrez l’acceptation des conditions d’utilisation et la date d’acceptation à l’aide de l’API Graph et des attributs étendus. Pour ce faire, vous pouvez utiliser à la fois des flux d’utilisateurs intégrés et des stratégies personnalisées. Nous vous recommandons de créer et d’utiliser les attributs extension_termsOfUseConsentDateTime et extension_termsOfUseConsentVersion .

  2. Créez une case à cocher obligatoire intitulée « Accepter les conditions d’utilisation » et enregistrez le résultat lors de l’inscription. Pour ce faire, vous pouvez utiliser à la fois des flux d’utilisateurs intégrés et des stratégies personnalisées.

  3. Azure AD B2C stocke les conditions d’utilisation, le contrat et l’acceptation de l’utilisateur. Vous pouvez utiliser l’API Graph pour interroger l’état d’un utilisateur en lisant l’attribut d’extension utilisé pour enregistrer la réponse (par exemple, lisez termsOfUseTestUpdateDateTime). Pour ce faire, vous pouvez utiliser à la fois des flux d’utilisateurs intégrés et des stratégies personnalisées.

  4. Exiger l’acceptation des conditions d’utilisation mises à jour en comparant la date d’acceptation à la date de la dernière version des conditions d’utilisation. Vous ne pouvez comparer les dates qu’à l’aide d’un flux d’utilisateurs personnalisé. Utilisez l’attribut étendu extension_termsOfUseConsentDateTime et comparez la valeur à la revendication de termsOfUseTextUpdateDateTime. Si l’acceptation est ancienne, forcez une nouvelle acceptation en affichant un écran déclaratif. Sinon, bloquez l’accès à l’aide de la logique de stratégie.

  5. Exiger l’acceptation des conditions d’utilisation mises à jour en comparant le numéro de version de l’acceptation au numéro de version accepté le plus récent. Vous ne pouvez comparer les numéros de version qu’à l’aide d’un flux d’utilisateurs personnalisé. Utilisez l’attribut étendu extension_termsOfUseConsentDateTime et comparez la valeur à la revendication de extension_termsOfUseConsentVersion. Si l’acceptation est ancienne, forcez une nouvelle acceptation en affichant un écran déclaratif. Sinon, bloquez l’accès à l’aide de la logique de stratégie.

Vous pouvez capturer l’acceptation des conditions d’utilisation dans les scénarios suivants :

  • Un nouvel utilisateur s’inscrit. Les conditions d’utilisation s’affichent et le résultat de l’acceptation est enregistré.
  • Un utilisateur se connecte alors qu’il a déjà accepté les conditions d’utilisation les plus récentes ou les conditions d’utilisation en vigueur. Les conditions d’utilisation ne sont pas affichées.
  • Un utilisateur se connecte alors qu’il n’a pas encore accepté les conditions d’utilisation les plus récentes ou les conditions d’utilisation en vigueur. Les conditions d’utilisation s’affichent et le résultat de l’acceptation est enregistré.
  • Un utilisateur qui s’est connecté a déjà accepté une ancienne version des conditions d’utilisation, qui sont maintenant mises à jour vers la dernière version. Les conditions d’utilisation s’affichent et le résultat de l’acceptation est enregistré.

L’image suivante montre le flux d’utilisateurs recommandé :

Organigramme montrant le flux d’utilisateurs d’acceptation recommandé

Voici un exemple de consentement aux conditions d’utilisation basé sur la date dans une revendication. Si la extension_termsOfUseConsentDateTime revendication est antérieure à 2025-01-15T00:00:00, forcez une nouvelle acceptation en vérifiant la termsOfUseConsentRequired revendication booléenne et en affichant un écran auto-affirmé.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentDateTime" TransformationMethod="GetCurrentDateTime">
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="currentDateTime" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequired" TransformationMethod="IsTermsOfUseConsentRequired">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="termsOfUseConsentDateTime" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="termsOfUseTextUpdateDateTime" DataType="dateTime" Value="2025-01-15T00:00:00" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="result" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Voici un exemple de consentement aux conditions d'utilisation spécifiques à une version dans le cadre d'une réclamation. Si la revendication n’est extension_termsOfUseConsentVersion pas égale à V1, forcez une nouvelle acceptation en vérifiant la termsOfUseConsentRequired revendication booléenne et en affichant un écran auto-affirmé.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetEmptyTermsOfUseConsentVersionForNewUser" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value=""/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentVersion" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="V1"/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequiredForVersion" TransformationMethod="CompareClaimToValue">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="inputClaim1" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="compareTo" DataType="string" Value="V1" />
      <InputParameter Id="operator" DataType="string" Value="not equal" />
      <InputParameter Id="ignoreCase" DataType="string" Value="true" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="outputClaim" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Étapes suivantes