次の方法で共有


Azure Active Directory B2C でユーザー アクセスを管理する

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください

この記事では、Azure Active Directory B2C (Azure AD B2C) を使用してアプリケーションへのユーザー アクセスを管理する方法について説明します。 アプリケーションでのアクセス管理には、次のものが含まれます。

  • 未成年者を特定し、アプリケーションへのユーザー アクセスを制御します。
  • 未成年者がアプリケーションを使用するために保護者の同意が必要です。
  • ユーザーから出生データと国/地域のデータを収集します。
  • 利用規約を取得し、アクセスを制限します。

Azure Active Directory B2C で、カスタム ポリシーは、主に、複雑なシナリオに取り組む用途向けに設計されています。 ほとんどのシナリオで、組み込みユーザー フローを使用することをお勧めします。 まだ行っていない場合は、Active Directory B2C でのカスタム ポリシーの概要に関する記事で、カスタム ポリシー スターター パックの詳細を確認してください。

マイナー アクセスを制御する

アプリケーションや組織は、未成年者がこの対象者を対象としていないアプリケーションやサービスの使用をブロックすることを決定する場合があります。 あるいは、アプリケーションや組織は、未成年者を受け入れ、その後、保護者の同意を管理し、ビジネスルールで規定され、規制で許可されている未成年者に許容されるエクスペリエンスを提供することを決定する場合があります。

ユーザーが未成年者として識別された場合は、Azure AD B2C のユーザー フローを次の 3 つのオプションのいずれかに設定できます。

  • 署名された JWT id_tokenをアプリケーションに送り返す: ユーザーがディレクトリに登録され、トークンがアプリケーションに返されます。 その後、アプリケーションはビジネス・ルールを適用して進行します。 たとえば、アプリケーションは保護者の同意プロセスを進める場合があります。 この方法を使用するには、アプリケーションから ageGroup 要求と consentProvidedForMinor 要求を受け取ることを選択します。

  • 署名されていない JSON トークンをアプリケーションに送信する: Azure AD B2C は、ユーザーが未成年者であることをアプリケーションに通知し、ユーザーの保護者の同意の状態を提供します。 その後、アプリケーションはビジネス・ルールを適用して進行します。 JSON トークンは、アプリケーションでの正常な認証を完了しません。 アプリケーションは、JSON トークンに含まれる要求 ( nameemailageGroupconsentProvidedForMinorなど) に従って、認証されていないユーザーを処理する必要があります。

  • ユーザーをブロックする: ユーザーが未成年者であり、保護者の同意が提供されていない場合、Azure AD B2C はブロックされていることをユーザーに通知できます。 トークンは発行されず、アクセスはブロックされ、登録体験中にユーザーアカウントは作成されません。 この通知を実装するには、ユーザーに通知し、適切なオプションを提示するための適切な HTML/CSS コンテンツ ページを提供します。 新規登録のために、アプリケーションでこれ以上の操作は必要ありません。

アプリケーションの規制によっては、成人として確認されたユーザーが保護者の同意を得る必要がある場合があります。 Azure AD B2C では、個人の年齢を確認した後、確認済みの成人が未成年者に親の同意を与えることができるエクスペリエンスは提供されません。 このエクスペリエンスは、アプリケーションまたは別のサービス プロバイダーによって提供される必要があります。

次に、保護者の同意を収集するためのユーザーフローの例を示します。

  1. Microsoft Graph API 操作は、ユーザーを未成年者として識別し、署名されていない JSON トークンの形式でユーザー データをアプリケーションに返します。

  2. アプリケーションは JSON トークンを処理し、未成年者に画面を表示して、親の同意が必要であることを通知し、オンラインで親の同意を要求します。

  3. Azure AD B2C は、ユーザーが通常どおりサインインできるサインイン体験を表示し、 legalAgeGroupClassification = "minorWithParentalConsent" を含むように設定されたトークンをアプリケーションに発行します。 アプリケーションは、親のメールアドレスを収集し、親が成人であることを確認します。 そのためには、国/地域のIDオフィス、ライセンスの確認、クレジットカードの証明など、信頼できる情報源を使用します。 検証が成功すると、アプリケーションは未成年者に Azure AD B2C ユーザー フローを使用してサインインするように求めます。 同意が拒否された場合 ( たとえば、legalAgeGroupClassification = "minorWithoutParentalConsent" の場合)、Azure AD B2C は JSON トークン (ログインではない) をアプリケーションに返して、同意プロセスを再開します。 必要に応じて、未成年者または成人が未成年者の電子メール アドレスまたは記録されている成人の電子メール アドレスに登録コードを送信することで、未成年者のアカウントへのアクセスを回復できるように、ユーザー フローをカスタマイズすることができます。

  4. このアプリケーションは、未成年者に同意を取り消すオプションを提供します。

  5. 未成年者または成人が同意を取り消すと、Microsoft Graph API を使用して consentProvidedForMinordenied に変更できます。 または、同意が取り消された未成年者を削除することを選択する場合があります。 必要に応じて、認証された未成年者 (または未成年者のアカウントを使用している親) が同意を取り消すことができるように、ユーザー フローをカスタマイズすることができます。 Azure AD B2C は consentProvidedForMinor拒否として記録します。

legalAgeGroupClassificationconsentProvidedForMinorageGroup の詳細については、「ユーザー リソースの種類」を参照してください。 カスタム属性の詳細については、「 カスタム属性を使用してコンシューマに関する情報を収集する」を参照してください。 Microsoft Graph API を使用して拡張属性に対処する場合は、属性の長いバージョン ( extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z など) を使用する必要があります。

生年月日と国・地域のデータを収集

アプリケーションは、Azure AD B2C を使用して、登録時にすべてのユーザーから生年月日 (DOB) と国/地域の情報を収集できます。 この情報がまだ存在しない場合、アプリケーションは次回の認証 (サインイン) 体験中にユーザーに情報を要求できます。 ユーザーは、生年月日と国/地域の情報を提供しないと続行できません。 Azure AD B2C では、この情報を使用して、その国/地域の規制基準に従って個人が未成年者と見なされるかどうかを判断します。

カスタマイズされたユーザー フローでは、DOB と国/地域の情報を収集し、Azure AD B2C 要求変換を使用して ageGroup を決定し、結果をディレクトリに保持する (または DOB と国/地域の情報を直接保持する) ことができます。

次の手順は、ユーザーの生年月日から ageGroup を計算するために使用されるロジックを示しています。

  1. リスト内の国/地域コードで国/地域を検索してみてください。 国/地域が見つからない場合は、 デフォルトにフォールバックします。

  2. MinorConsent ノードが country/region 要素に存在する場合:

    ある。 ユーザーが成人と見なされるには、その生年月日を計算します。 たとえば、現在の日付が 2015 年 3 月 14 日で、 MinorConsent が 18 歳の場合、生年月日は 2000 年 3 月 14 日以降である必要があります。

    b。 最小生年月日と実際の生年月日を比較します。 最小生年月日がユーザーの生年月日より前の場合、計算では年齢グループの計算として [マイナー] が返されます。

  3. MinorNoConsentRequired ノードが国/地域要素に存在する場合、MinorNoConsentRequired の値を使用して手順 2a と 2b を繰り返します。 2b の出力は、最小生年月日がユーザーの生年月日より前である場合、 MinorNoConsentRequired を返します。

  4. どちらの計算も true を返さない場合、計算は Adult を返します。

アプリケーションが他の方法で DOB または国/地域のデータを確実に収集した場合、アプリケーションは Graph API を使用して、この情報でユーザー レコードを更新できます。 例えば次が挙げられます。

  • ユーザーが成人であることがわかっている場合は、ディレクトリ属性 ageGroupAdult の値で更新します。
  • ユーザーが未成年者であることがわかっている場合は、ディレクトリ属性 ageGroupMinor の値に更新し、必要に応じて consentProvidedForMinor を設定します。

マイナーな計算ルール

年齢制限には、未成年者と見なされなくなった年齢と、未成年者が親の同意を得なければならない年齢の 2 つの年齢値が含まれます。 次の表に、未成年者と同意が必要な未成年者を定義するために使用される年齢ルールを示します。

国/リージョン 国/地域名 未成年者の同意年齢 未成年者の年齢
既定値 無し 無し 18
AEの アラブ首長国連邦 無し 21 (二十一)
オーストリア 14 18
である ベルギー 14 18
BGの ブルガリア 16 18
BHの バーレーン 無し 21 (二十一)
センチメートル カメルーン 無し 21 (二十一)
CYについて キプロス 16 18
CZの チェコ共和国 16 18
DE ドイツ 16 18
DKの デンマーク 16 18
EEの エストニア 16 18
例えば エジプト 無し 21 (二十一)
ES スペイン 13 18
フランス フランス 16 18
ギガバイト イギリス 13 18
GRの ギリシャ 16 18
人事部 クロアチア 16 18
ハンガリー 16 18
IE (インターネットエクスプローラー) アイルランド 13 18
情報技術 イタリア 16 18
韓国 韓国 14 18
LT(リトリー) リトアニア 16 18
LUの ルクセンブルク 16 18
LVの ラトビア 16 18
マルタ 16 18
NAの ナミビア 無し 21 (二十一)
オランダ オランダ 16 18
損益 ポーランド 13 18
パートタイム ポルトガル 16 18
ロウ ルーマニア 16 18
SEの スウェーデン 13 18
SG シンガポール 無し 21 (二十一)
国際単位系 (SI) スロベニア 16 18
SKの スロバキア 16 18
TDの チャド 無し 21 (二十一)
番目 タイ 無し 20
TWの 台湾 無し 20
アメリカ アメリカ合衆国 13 18

利用規約のキャプチャ

アプリケーションを開発するときは、通常、ユーザーがアプリケーション内で利用規約に同意したことをキャプチャし、ユーザーディレクトリからの参加はまったくないか、またはごくわずかです。 ただし、Azure AD B2C ユーザー フローを使用して、ユーザーの利用規約への同意を収集し、同意が許可されない場合はアクセスを制限し、最新の同意の日付と最新バージョンの利用規約の日付に基づいて、利用規約の将来の変更への同意を強制することは可能です。

利用規約には 、「第三者とデータを共有することへの同意」も含まれる場合があります。地域の規制やビジネス・ルールに応じて、ユーザーが両方の条件を結合して受け入れるかどうかを収集することも、一方の条件を受け入れてもう一方の条件を受け入れないようにすることもできます。

次の手順では、利用規約を管理する方法について説明します。

  1. 使用条件への同意と同意日を Graph API と拡張属性を使用して記録します。 これを行うには、組み込みのユーザー フローとカスタム ポリシーの両方を使用します。 extension_termsOfUseConsentDateTime 属性と extension_termsOfUseConsentVersion 属性を作成して使用することをお勧めします。

  2. 「利用規約に同意する」というラベルの付いた必須チェックボックスを作成し、サインアップ時に結果を記録します。 これを行うには、組み込みのユーザー フローとカスタム ポリシーの両方を使用します。

  3. Azure AD B2C には、使用条件、契約、およびユーザーの同意が格納されます。 Graph API を使用して、応答の記録に使用される拡張属性を読み取ることで、任意のユーザーの状態を照会できます ( たとえば、termsOfUseTestUpdateDateTime を読み取ります)。 これを行うには、組み込みのユーザー フローとカスタム ポリシーの両方を使用します。

  4. 更新された利用規約への同意を求めるには、同意日と最新バージョンの利用規約の日付を比較します。 日付を比較できるのは、カスタム ユーザー フローを使用する場合のみです。 拡張属性 extension_termsOfUseConsentDateTime を使用し、値を termsOfUseTextUpdateDateTime の要求と比較します。 受け入れが古い場合は、セルフアサート画面を表示して新しい受け入れを強制します。 それ以外の場合は、ポリシー ロジックを使用してアクセスをブロックします。

  5. 更新された利用規約への同意を求めるには、同意したバージョン番号と最後に同意したバージョン番号を比較します。 バージョン番号を比較できるのは、カスタム ユーザー フローを使用する場合のみです。 拡張属性 extension_termsOfUseConsentDateTime を使用し、値を extension_termsOfUseConsentVersion のクレームと比較します。 受け入れが古い場合は、セルフアサート画面を表示して新しい受け入れを強制します。 それ以外の場合は、ポリシー ロジックを使用してアクセスをブロックします。

次のシナリオでは、使用条件への同意をキャプチャできます。

  • 新しいユーザーがサインアップしています。 利用規約が表示され、同意結果が保存されます。
  • 以前に最新のまたはアクティブな利用規約に同意したユーザーがサインインしています。 利用規約は表示されません。
  • ユーザーがサインインしていますが、最新の利用規約またはアクティブな利用規約にまだ同意していません。 利用規約が表示され、同意結果が保存されます。
  • ユーザーがサインインしているユーザーは、古いバージョンの利用規約に既に同意しており、現在は最新バージョンに更新されています。 利用規約が表示され、同意結果が保存されます。

次の図は、推奨されるユーザー フローを示しています。

推奨受け入れユーザーフローを示すフローチャート図

以下は、請求における日付ベースの利用規約の同意の例です。 extension_termsOfUseConsentDateTime 要求が 2025-01-15T00:00:00 より古い場合は、termsOfUseConsentRequired ブール要求を確認し、自己アサート画面を表示して、新しい承認を強制します。

<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>

次に示すのは、クレームにおけるバージョンベースの利用規約の同意の例です。 extension_termsOfUseConsentVersion 要求が V1 と等しくない場合は、termsOfUseConsentRequired ブール要求を確認し、セルフアサート画面を表示して、新しい受け入れを強制します。

<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>

次のステップ