Partager via

Gérer l’accès utilisateur dans Azure Active Directory B2C

  • Article

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

  • Identification des mineurs et contrôle de l’accès utilisateur à votre application.
  • Obligation d’obtenir le consentement parental pour que les mineurs utilisent vos applications.
  • Collecte de données sur la date de naissance et le pays/région des utilisateurs.
  • Capture de l’acceptation des conditions d’utilisation et de régulation de l’accès.

Notes

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ôle d’accès des mineurs

Les applications et les organisations peuvent décider d’empêcher les mineurs d’utiliser des applications et des services qui ne sont pas adaptés à ce public. Les applications et les organisations peuvent aussi décider d’accepter les mineurs, et par conséquent gérer le consentement parental et fournir des expériences autorisées aux mineurs comme stipulées par les règles d’entreprise et autorisées par la législation.

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

  • Renvoyer un jeton id_token JWT signé à l’application : L’utilisateur est enregistré dans le répertoire, et un jeton est retourné à l’application. L’application continue à s’exécuter conformément aux règles d’entreprise. Par exemple, l’application peut lancer un processus de consentement parental. Pour utiliser cette méthode, choisissez de recevoir les revendications ageGroup et consentProvidedForMinor à partir de l’application.

  • Envoyer un jeton JSON non signé à l’application : Azure AD B2C indique à l’application que l’utilisateur est mineur, et fournit l’état de consentement parental de l’utilisateur. L’application continue à s’exécuter conformément aux règles d’entreprise. Un jeton JSON ne permet pas d’effectuer une authentification réussie avec l’application. L’application doit traiter l’utilisateur non authentifié conformément aux revendications incluses dans le jeton JSON, qui peut inclure name, email, ageGroup et consentProvidedForMinor.

  • Bloquer l’utilisateur : Si un utilisateur est mineur et que le consentement parental n’a pas été donné, Azure AD B2C peut informer l’utilisateur qu’il est bloqué. Aucun jeton n’est émis, l’accès est bloqué et le compte d’utilisateur n’est pas créé au moment de l’inscription. Pour implémenter cette notification, vous fournissez une page de contenu HTML/CSS appropriée afin d’informer l’utilisateur et de présenter les options appropriées. Aucune action supplémentaire émanant de l’application n’est requise pour les nouvelles inscriptions.

Selon la législation relative à l’application, il peut être nécessaire d’obtenir le consentement parental auprès d’un utilisateur adulte vérifié. Azure AD B2C ne fournit pas d’expérience permettant de vérifier l’âge d’un individu, puis d’autoriser un adulte vérifié à donner 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 utilisateur pour le recueil du consentement parental :

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

  2. L’application traite le jeton JSON et affiche un écran à l’intention du mineur pour l’informer que le consentement parental est nécessaire et pour le demander à un parent en ligne.

  3. Azure AD B2C affiche un parcours d’authentification que l’utilisateur peut suivre pour se connecter normalement, et émet un jeton à l’application qui doit inclure legalAgeGroupClassification = "minorWithParentalConsent" . L’application collecte l’adresse e-mail du parent et vérifie que ce dernier est un adulte. Pour ce faire, elle fait appel à une source de confiance, par exemple un bureau des cartes d’identité national/régional, la vérification du permis de conduire ou une preuve de possession d’une carte de crédit. Si la vérification réussit, l’application demande au mineur de se connecter à l’aide du flux utilisateur Azure AD B2C. Si le consentement est refusé (par exemple, si legalAgeGroupClassification = "minorWithoutParentalConsent" ), Azure AD B2C retourne un jeton JSON (et non un compte de connexion) à destination de l’application afin de recommencer le processus de consentement. Il est possible de personnaliser le flux utilisateur de façon à ce qu’un mineur ou un adulte puisse récupérer 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é.

  4. L’application permet au mineur de révoquer le consentement.

  5. Quand un mineur ou un adulte révoque le consentement, l’API Microsoft Graph peut être utilisée pour changer la valeur de consentProvidedForMinor en denied. L’application peut également supprimer un mineur dont le consentement a été révoqué. Il est possible de personnaliser le flux utilisateur de façon à ce que le mineur authentifié (ou le parent utilisant le compte du mineur) puisse révoquer le consentement. Azure AD B2C enregistre consentProvidedForMinor avec la valeur denied.

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 recueillir des informations sur vos consommateurs. Quand vous traitez des attributs étendus en utilisant l’API Microsoft Graph, vous devez utiliser la version longue de l’attribut, comme extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth : 2011-01-01T00:00:00Z.

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

Les applications peuvent se servir d’Azure AD B2C pour recueillir des informations sur la date de naissance et le pays/région de tous les utilisateurs au moment de l’inscription. Si ces informations ne sont pas déjà disponibles, l’application peut les demander à l’utilisateur lors de sa prochaine authentification (connexion). Les utilisateurs ne peuvent pas continuer sans fournir des informations sur leur date de naissance et leur pays/région. Azure AD B2C utilise ces informations pour déterminer si l’utilisateur est considéré comme un mineur d’après la législation du pays/région en question.

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

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

  1. Essayez de trouver le pays ou la région à l’aide de leur code dans la liste. Si vous ne trouvez pas le pays ou la région, revenez à la valeur Default.

  2. Si le nœud MinorConsent est présent dans l’élément de pays/région :

    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, la date de naissance doit être au plus tard le 14 mars 2000.

    b. Comparez la date de naissance minimale avec la date de naissance réelle. Si la date de naissance minimale se situe avant la date de naissance de l’utilisateur, le calcul renvoie Minor lors du calcul de la tranche d’âge.

  3. Si le nœud MinorNoConsentRequired est présent dans l’élément de pays/région, répétez les étapes 2a et 2 b avec la valeur issue de MinorNoConsentRequired. La sortie de l’étape 2b retourne MinorNoConsentRequired si la date de naissance minimale se situe avant la date de naissance de l’utilisateur.

  4. Si aucun des deux calculs ne renvoie la valeur true, le calcul renvoie Adult.

Si une application a recueilli les données sur la date de naissance et le pays/région par d’autres méthodes fiables, elle peut utiliser l’API Graph pour mettre à jour l’enregistrement utilisateur avec ces informations. Par exemple :

  • Si un utilisateur est connu en tant qu’adulte, mettez à jour l’attribut ageGroup du répertoire avec la valeur Adult.
  • Si un utilisateur est connu en tant que mineur, mettez à jour l’attribut de répertoire ageGroup avec la valeur Minor et définissez consentProvidedForMinor, le cas échéant.

Règles de calcul mineures

La vérification de l’âge implique deux valeurs d’âge : l’âge auquel un utilisateur n’est plus considéré comme mineur et l’âge auquel un mineur doit obtenir un accord parental. Le tableau suivant liste les règles d’âge utilisées pour déterminer si un utilisateur est mineur et s’il a besoin d’un accord parental.

Pays/région Nom du pays/de la région Accord parental Majorité
Default None None 18
AE Émirats Arabes Unis None 21
AT Autriche 14 18
BE Belgique 14 18
BG Bulgarie 16 18
BH Bahreïn None 21
CM Cameroun None 21
CY Chypre 16 18
CZ République tchèque 16 18
DE Allemagne 16 18
DK Danemark 16 18
EE Estonie 16 18
EG Égypte None 21
ES Espagne 13 18
FR France 16 18
Go Royaume-Uni 13 18
GR Grèce 16 18
HR Croatie 16 18
HU Hongrie 16 18
IE Irlande 13 18
IT 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 None 21
NL Pays-Bas 16 18
PL Pologne 13 18
PT Portugal 16 18
RO Roumanie 16 18
SE Suède 13 18
SG Singapour None 21
SI Slovénie 16 18
SK Slovaquie 16 18
TD Tchad None 21
MJ Thaïlande None 20
TW Taïwan None 20
US États-Unis 13 18

Capturer l’acceptation des conditions d’utilisation

Lorsque vous développez une application, vous capturez généralement l’acceptation des conditions d’utilisation par les utilisateurs au sein de leurs applications, sans aucune ou très peu de participation provenant du répertoire utilisateur. Cependant, il est possible d’utiliser un flux utilisateur Azure AD B2C pour recueillir l’acceptation des conditions d’utilisation par l’utilisateur, restreindre l’accès si l’accord n’a pas été obtenu, et appliquer l’acceptation des modifications futures pour les conditions d’utilisation en fonction de la date de dernière acceptation et de la date de dernière version des conditions d’utilisation.

Les Conditions d’utilisation peuvent également inclure l’option « Consent to share data with third parties » (Accepter de partager des données avec des tiers). Selon les réglementations locales et les règles d’entreprise, vous pouvez collecter l’acceptation d’un utilisateur des deux conditions combinées, 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. Cette opération est possible avec les flux utilisateur intégrés et les 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 pendant l’inscription. Cette opération est possible avec les flux utilisateur intégrés et les stratégies personnalisées.

  3. Azure AD B2C stocke les données d’acceptation liées aux conditions d’utilisation 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 qui sert à enregistrer la réponse (par exemple en lisant termsOfUseTestUpdateDateTime). Cette opération est possible avec les flux utilisateur intégrés et les stratégies personnalisées.

  4. Exigez l’acceptation des conditions d’utilisation mises à jour en comparant la date d’acceptation avec la date de dernière version des conditions d’utilisation. Vous pouvez comparer les dates uniquement en utilisant un flux d’utilisateur 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éclaré automatiquement. Sinon, bloquez l’accès à l’aide de la logique de stratégie.

  5. Exigez l’acceptation des conditions d’utilisation mises à jour en comparant le numéro de version de l’acceptation avec le numéro de la dernière version acceptée. Vous pouvez comparer les numéros de version uniquement en utilisant un flux d’utilisateur 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éclaré automatiquement. 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 d’acceptation est stocké.
  • Un utilisateur qui a déjà accepté les conditions d’utilisation actives ou les plus récentes se connecte. Les conditions d’utilisation ne s’affichent pas.
  • Un utilisateur qui n’a pas encore accepté les conditions d’utilisation actives ou les conditions d’utilisation les plus récentes se connecte. Les conditions d’utilisation s’affichent et le résultat d’acceptation est stocké.
  • Un utilisateur qui a déjà accepté une ancienne version des conditions d’utilisation, désormais mises à jour vers la dernière version, se connecte. Les conditions d’utilisation s’affichent et le résultat d’acceptation est stocké.

L’image suivante montre le flux utilisateur recommandé :

Diagramme illustrant le flux utilisateur d'acceptation recommandé

Voici un exemple de consentement pour des conditions d’utilisation basées sur la date dans une revendication. Si la revendication de extension_termsOfUseConsentDateTime est plus ancienne que 2025-01-15T00:00:00, forcez une nouvelle acceptation en vérifiant la revendication booléenne termsOfUseConsentRequired et en affichant un écran auto-déclaré.

<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 pour des conditions d’utilisation basées sur la version dans une revendication. Si la revendication de extension_termsOfUseConsentVersion n’est pas égale à V1, forcez une nouvelle acceptation en vérifiant la revendication booléenne termsOfUseConsentRequired et en affichant un écran auto-déclaré.

<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