チュートリアル: Azure Active Directory B2C を使用して IDEMIA Mobile ID を構成する

重要

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

開始する前に

Azure Active Directory B2C (Azure AD B2C) には、アプリケーションとのユーザー操作を定義する 2 つの方法があります。定義済みのユーザー フローまたは構成可能なカスタム ポリシーです。 ユーザー フローとカスタム ポリシーの概要を参照してください

Azure AD B2C と IDEMIA Mobile ID の統合

IDEMIA は、顔 ID やフィンガープリントなどの生体認証サービスを提供します。これにより、不正行為や資格情報の再利用が軽減されます。 モバイル ID を使用すると、市民は、信頼できる政府発行のデジタル ID を、物理的な ID の補完として利用できます。 モバイル ID は、自己選択の PIN、タッチ ID、または顔 ID を使用して ID を検証します。 市民は、トランザクションに必要な情報を共有することで、ID を制御します。 自動車 (DMV) の多くの州部門では、モバイル ID が使用されています。

詳細については、「idemia.com: IDEMIA」を参照してください。

シナリオの説明

モバイル ID の統合には、次のコンポーネントが含まれています。

• Azure AD B2C – ユーザー資格情報を検証する承認サーバー
  • ID プロバイダー (IdP) とも呼ばれます。
• IDEMIA モバイル ID - Azure AD B2C 外部プロバイダーとして構成された OpenID Connect (OIDC) プロバイダー
  • Azure AD B2C テナントへの ID プロバイダーの追加に関するページを参照してください。
• IDEMIA モバイル ID アプリケーション - スマートフォン上のアプリ内の運転免許証または状態発行 ID のデジタル バージョン
  • 「IDEMIA Mobile ID」を参照してください

モバイル ID はデジタル化された ID ドキュメントであり、DMV が個々の ID を検証するために使用するポータブル モバイル ID トークンです。 署名されたデジタル化された ID は、エッジ上の ID としてユーザーの携帯電話に格納されます。 署名された資格情報を使用すると、年齢の証明、財務上の知り合い、顧客のアカウント アクセスなどの ID サービスへのアクセスが容易になります。

次の図は、モバイル ID を使用したサインアップとサインインのユーザー フローを示しています。

1. ユーザーは、デバイスとモバイル ID を使用して Azure AD B2C サインイン ページ (返信者) にアクセスし、トランザクションを実行します。
2. Azure AD B2C は ID チェックを実行します。 OIDC 承認コード フローを使用して IDEMIA ルーターにユーザーをリダイレクトします。
3. ルーターは、認証と承認要求の詳細を使用して、ユーザーのモバイル アプリに生体認証チャレンジを送信します。
4. セキュリティによっては、PIN の入力、ライブ 自撮り、またはその両方など、詳細を入力するように求められる場合があります。
5. 認証応答は、所有、プレゼンス、および同意の証明を提供します。 応答はルーターに戻ります。
6. ルーターはユーザー情報を検証し、結果と共に Azure AD B2C に応答します。
7. ユーザーはアクセスを許可または拒否されます。

モバイル ID を有効にする

作業を開始するには、idemia.com の「Get in touch」ページに移動して、デモを要求します。 要求フォームのテキスト フィールドで、Azure AD B2C 統合に関心があることを示します。

Mobile ID と Azure AD B2C の統合

次のセクションを使用して、統合プロセスの準備と実行を行います。

[前提条件]

開始するには、次のものが必要です。

• IDEMIA、米国の州が発行したモバイル ID 資格情報 (mID) を持つユーザーへのアクセス

  • または、テスト フェーズの間は、IDEMIA の mID デモ アプリケーション

• Azure サブスクリプション

  • お持ちでない場合は、Azure 無料アカウントを取得してください。

• Azure サブスクリプションにリンクされた Azure AD B2C テナント

• Azure AD B2C テナントに登録されているビジネス Web アプリケーション

  • テスト用に、デコードされたトークンの内容を含む Microsoft Web アプリケーションである https://jwt.msを構成する

  注

  トークンの内容がブラウザーから離れることはありません。

mID の証明書利用者アプリケーションを送信する

モバイル ID の統合中に、次の情報が提供されます。

プロパティ	説明
アプリケーション名	Azure AD B2C または別のアプリケーション名
Client_ID	ID プロバイダー (IdP) からの一意の識別子
クライアント シークレット	証明書利用者アプリケーションが IDEMIA IdP で認証するために使用するパスワード
メタデータ エンドポイント	トークン発行者の構成ドキュメント (OpenID の既知の構成エンドポイントとも呼ばれます) を指す URL
リダイレクト URI	https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp たとえば、https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp のように指定します。 カスタム ドメインを使用する場合は、「 https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp」と入力します。
サインアウト後のリダイレクト URI	https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout サインアウト要求を送信します。

注

Azure AD B2C で IdP を構成するには、後でクライアント ID とクライアント シークレットが必要です。

ポリシー キーを作成する

示されている IDEMIA クライアント シークレットを Azure AD B2C テナントに格納します。 次の手順では、Azure AD B2C テナントでディレクトリを使用します。

1. Azure portal にサインインします。
2. ポータルのツール バーで、[ ディレクトリとサブスクリプション] を選択します。
3. ポータルの設定の [ ディレクトリとサブスクリプション ] ページの ディレクトリ名 の一覧で、Azure AD B2C ディレクトリを見つけます
4. [ 切り替え] を選択します。
5. Azure portal の左上隅にある [ すべてのサービス] を選択します。
6. Azure AD B2C を検索して選択します。
7. [概要] ページで、[Identity Experience Framework] を選択します。
8. [ポリシー キー] を選択します。
9. [] を選択し、[] を追加します。
10. [オプション] では、[手動] を選びます。
11. ポリシー キーの名前を入力します。 たとえば、IdemiaAppSecret のようにします。 プレフィックス B2C_1A_ がキー名に追加されます。
12. [ シークレット] に、指定したクライアント シークレットを入力します。
13. [キー使用法] には [署名] を選択します。
14. を選択してを作成します。

モバイル ID を外部 IdP として構成する

ユーザーが Mobile ID でサインインできるようにするには、IDEMIA をクレーム プロバイダーとして定義します。 このアクションにより、Azure AD B2C がエンドポイントを介して通信することが保証されます。これにより、Azure AD B2C が biometry を使用してユーザー認証を検証するために使用する要求が提供されます。

IDEMIA をクレーム プロバイダーとして定義するには、ポリシー拡張ファイルの ClaimsProvider 要素に追加します。

     <TechnicalProfile Id="Idemia-Oauth2">
          <DisplayName>IDEMIA</DisplayName>
          <Description>Login with your IDEMIA identity</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="METADATA">https://idp.XXXX.net/oxauth/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid id_basic mt_scope</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="token_endpoint_auth_method">client_secret_basic</Item>
            <Item Key="ClaimsEndpoint">https://idp.XXXX.net/oxauth/restv1/userinfo</Item>
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_IdemiaAppSecret" />
</CryptographicKeys>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr_values" DefaultValue="loa-2" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName1" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="lastName1" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="idemia" />
            <OutputClaim ClaimTypeReferenceId="documentId" />
            <OutputClaim ClaimTypeReferenceId="address1" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
           

client_idアプリケーション登録のアプリケーション ID に設定します。

プロパティ	説明
範囲	OpenID Connect (OIDC) の場合、最小要件はスコープ パラメーターを openid に設定することです。 スペース区切りリストとしてさらにスコープを追加します。
redirect_uri	この場所は、ユーザー エージェントが承認コードを Azure AD B2C に送信する場所です。
レスポンス・タイプ (response_type)	承認コード フローの場合は、コードを選択します。
acr_values	このパラメーターは、ユーザーが認証時に実行する必要がある認証方法を制御します。

以下の値のうちの一つを選択します:

パラメーター値	ユーザー認証プロセスへの影響
loa-2	暗号化ベースの Microsoft Entra 多要素認証のみ
loa-3	暗号化ベースの MFA に加えて、もう 1 つの要素
loa-4	暗号化ベースの MFA に加えて、ユーザーが PIN と生体認証を実行する

/userinfo エンドポイントは、承認要求で要求されたスコープの要求を提供します。 <mt_scope>には、名、姓、運転免許証番号などの要求があります。 スコープの要求セットは、探索 API の scope_to_claims_mapping セクションで公開されます。 Azure AD B2C は要求エンドポイントから要求を要求し、OutputClaims 要素で返します。 ポリシー内の要求名を IdP 内の名前にマップすることが必要な場合があります。 ClaimSchema 要素で要求の種類を定義します。

<ClaimType Id="documentId">
     <DisplayName>documentId</DisplayName>
     <DataType>string</DataType>
</ClaimType>
<ClaimType Id="address1">
     <DisplayName>address</DisplayName>
     <DataType>string</DataType>
</ClaimType>

ユーザー体験を追加する

これらの手順では、IdP は設定されていますが、サインイン ページには表示されません。 カスタム ユーザー体験がない場合は、テンプレート ユーザー体験をコピーします。

1. スターター パックから、 TrustFrameworkBase.xml ファイルを開きます。
2. ID=SignUpOrSignInを含むUserJourneys要素の内容を見つけてコピーします。
3. TrustFrameworkExtensions.xml を開きます。
4. UserJourneys 要素を見つけます。 要素がない場合は、要素を追加します。
5. UserJourney 要素の内容を UserJourneys 要素の子として貼り付けます。
6. ユーザー体験 ID の名前を変更します。 たとえば、ID=CustomSignUpSignIn のようにします。

IdP をユーザー体験に追加する

ユーザー体験がある場合は、新しい IdP を追加します。 最初にサインイン ボタンを追加し、それをアクション (作成した技術プロファイル) にリンクします。

1. ユーザー体験で、Type=CombinedSignInAndSignUp または Type=ClaimsProviderSelection のオーケストレーション ステップ要素を見つけます。 通常は、オーケストレーションの最初の手順です。 ClaimsProviderSelections 要素には、ユーザーがサインインする IdP リストがあります。 要素コントロールの順序は、ユーザーが表示するサインイン ボタンの順序です。
2. ClaimsProviderSelection XML 要素を追加します。
3. TargetClaimsExchangeId 値をフレンドリ名に設定します。
4. ClaimsExchange 要素を追加します。
5. Id をターゲット要求交換 ID の値に設定します。
6. TechnicalProfileReferenceId の値を、作成した技術プロファイル ID に更新します。

次の XML は、IdP を使用したユーザー体験の最初の 2 つのオーケストレーション手順を示しています。

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="IdemiaExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="IdemiaExchange" TechnicalProfileReferenceId="Idemia-Oauth2" />
  </ClaimsExchanges>
</OrchestrationStep>

依存先パーティーポリシーを構成する

証明書利用者ポリシー ( SignUpSignIn.xmlなど) は、Azure AD B2C が実行するユーザー体験を指定します。

1. 信頼する側で DefaultUserJourney 要素を見つけてください。
2. ReferenceId を、IdPを追加したユーザージャーニーIDと一致するように更新します。

次の例では、 CustomSignUpOrSignIn ユーザー体験の ReferenceId が CustomSignUpOrSignIn に設定されています。

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

カスタム ポリシーをアップロードする

次の手順では、Azure AD B2C テナントでディレクトリを使用します。

1. Azure portal にサインインします。

2. ポータルのツール バーで、[ ディレクトリとサブスクリプション] を選択します。

3. ポータルの 設定の [ディレクトリとサブスクリプション ] ページの [ディレクトリ名 ] 一覧で、Azure AD B2C ディレクトリを見つけます。

4. [ 切り替え] を選択します。

5. Azure portal で、 [Azure AD B2C] を検索して選択します。

6. [ ポリシー] で、[ Identity Experience Framework] を選択します。

7. [ カスタム ポリシーのアップロード] を選択します。

8. 変更した 2 つのポリシー ファイルを次の順序でアップロードします。

   • 拡張機能ポリシー (例: TrustFrameworkExtensions.xml
   • 証明書利用者ポリシー (SignUpSignIn.xml など)

カスタム ポリシーをテストする

1. 関連パーティポリシー（例: B2C_1A_signup_signin）を選択してください。
2. [ アプリケーション] で、登録した Web アプリケーションを選択します。
3. https://jwt.msが応答 URL に表示されます。
4. [今すぐ実行] を選択します。
5. サインアップまたはサインイン ページで、[ IDEMIA] を選択します。
6. ブラウザーが https://jwt.msにリダイレクトされます。 Azure AD B2C によって返されるトークンの内容を確認します。

詳細情報: チュートリアル: Azure AD B2C に Web アプリケーションを登録する

次のステップ

• Azure AD B2C カスタム ポリシーの概要
• チュートリアル: Azure AD B2C でユーザー フローとカスタム ポリシーを作成する
• idemia.comにアクセスして、より高いプライバシーでモバイルIDを証明する