Microsoft Entra 多要素認証での外部の方法のプロバイダーの参照 (プレビュー)

このトピックでは、外部認証プロバイダーが Microsoft Entra 多要素認証 (MFA) に接続する方法について説明します。 外部認証プロバイダーは、外部認証方法 (EAM) として Microsoft Entra ID テナントと統合できます。 EAM は、リソースまたはアプリケーションへのアクセスに関する MFA 要件の 2 番目の要素を満たすことができます。 EAM には、少なくとも Microsoft Entra ID P1 ライセンスが必要です。

ユーザーがサインインすると、そのテナント ポリシーが評価されます。 認証要件は、ユーザーがアクセスしようとするリソースに基づいて決定されます。

パラメーターに応じて、複数のポリシーがサインインに適用される場合があります。 これらのパラメーターには、ユーザーとグループ、アプリケーション、プラットフォーム、サインインのリスク レベルなどが含まれます。

認証要件に基づいて、ユーザーは MFA 要件を満たすために別の要素でサインインする必要がある場合があります。 2 番目の要素は、最初の要素の種類を補完する必要があります。

EAM はテナント管理者によって Microsoft Entra ID に追加されます。テナントで MFA に EAM が必要な場合、Microsoft Entra ID が次の両方を検証した後、サインインは MFA 要件を満たしていると見なされます。

• 最初の要素が Microsoft Entra ID で完了した
• 2 番目の要素が EAM で完了した

この検証は、次の 2 種類以上の方法に対する MFA 要件を満たしています。

• 知っていること (知識)
• 持っていること (所有)
• 自分そのもの (固有性)

EAM は Open ID Connect (OIDC) 上に実装されます。 この実装には、少なくとも 3 つの公開されているエンドポイントが必要です。

• プロバイダー メタデータの検出に従った OIDC ディスカバリーエンドポイント
• 有効な OIDC 認証エンドポイント
• プロバイダーの公開証明書が発行される URL

EAM でのサインインがどのように機能するかを詳しく見てみましょう。

1. ユーザーは、パスワードなどの最初の要素を使って、Microsoft Entra ID で保護されているアプリケーションにサインインしようとします。
2. Microsoft Entra ID は、別の要素を満たす必要があると判断します。 たとえば、条件付きアクセス ポリシーには MFA が必要です。
3. ユーザーは 2 番目の要素として EAM を選びます。
4. Microsoft Entra ID は、ユーザーのブラウザー セッションを EAM URL にリダイレクトします。
   1. この URL は、管理者が EAM を作成したときにプロビジョニングした探索 URL から検出されます。
   2. アプリケーションは、ユーザーとテナントを識別する情報を含む、期限切れまたは期限切れ間近のトークンを提供します。
5. 外部認証プロバイダーは、トークンが Microsoft Entra ID からのものであることを検証し、トークンの内容を確認します。
6. 外部認証プロバイダーは、必要に応じて Microsoft Graph を呼び出して、ユーザーに関するその他の情報をフェッチする場合があります。
7. 外部認証プロバイダーは、何らかの資格情報によるユーザーの認証など、必要と思われるアクションを実行します。
8. 外部認証プロバイダーは、必要なすべてのクレームを含む有効なトークンを使って、ユーザーを Microsoft Entra ID にリダイレクトします。
9. Microsoft Entra ID は、トークンの署名が構成された外部認証プロバイダーからのものであることを検証し、トークンの内容を確認します。
10. Microsoft Entra ID は、要件に照らしてトークンを検証します。
11. 検証が成功した場合、ユーザーは MFA 要件を満たしています。 ユーザーは他のポリシー要件も満たさなければならない場合があります。

Microsoft Entra ID を使って新しい外部認証プロバイダーを構成する

EAM が id_token_hint を発行するには、統合を代表するアプリケーションが必要です。 アプリケーションは次の 2 つの方法で作成できます。

• 外部プロバイダーを使う各テナントに作成します。
• 1 つのマルチテナント アプリケーションとして作成します。 特権ロール管理者は、テナントの統合を有効にするために同意を付与する必要があります。

マルチテナント アプリケーションを使うと、各テナントでの構成ミスの可能性が低くなります。 また、プロバイダーは、各テナントに変更を加えるのではなく、応答 URL などのメタデータを 1 か所で変更できるようになります。

マルチテナント アプリケーションを構成するには、プロバイダー管理者はまず次のことを行う必要があります。

1. Microsoft Entra ID テナントがまだない場合は、作成します。

2. テナントにアプリケーションを登録します。

3. アプリケーションのサポートされているアカウントの種類を次のように設定します: 任意の組織ディレクトリのアカウント (任意の Microsoft Entra ID テナント - マルチテナント)。

4. 委任されたアクセス許可 openid と Microsoft Graph の profile プロファイルをアプリケーションに追加します。

5. このアプリケーションではスコープを公開しないでください。

6. 外部 ID プロバイダーの有効な authorization_endpoint URL をそのアプリケーションに応答 URL として追加します。

   注

   プロバイダーの探索ドキュメントで提供される authorization_endpoint は、アプリケーションの登録のリダイレクト URL として追加する必要があります。 それ以外の場合は、次のエラーが表示されます。"ENTRA IDSTS50161: 外部クレーム プロバイダーの認可 URL を検証できませんでした。"

アプリケーションの登録プロセスでは、いくつかのプロパティを持つアプリケーションが作成されます。 このシナリオでは、これらのプロパティが必要です。

各テナントのアプリケーションも、統合をサポートする有効なモデルです。 シングルテナント登録を使う場合、テナント管理者は、シングルテナント アプリケーション用に上記の表のプロパティを使ってアプリケーションの登録を作成する必要があります。

省略可能な要求の構成

プロバイダーは、 id_tokenの省略可能な要求を使用して、より多くの要求を構成できます。

EAM を Microsoft Entra ID に追加する

外部 ID プロバイダー情報は、各テナントの認証方法のポリシーに格納されます。 プロバイダー情報は externalAuthenticationMethodConfiguration 型の認証方法として格納されます。

各プロバイダーには、ポリシーのリスト オブジェクトに 1 つのエントリが含まれます。 各エントリは次の内容を持つ必要があります。

• 方法が有効かどうか
• 方法を使用できる対象グループ
• 方法を使用できない除外グループ

条件付きアクセス管理者は、MFA 許可が必要なポリシーを作成して、ユーザー サインインの MFA 要件を設定できます。 現在、外部認証方法は認証強度でサポートされていません。

Microsoft Entra 管理センターで外部認証方法を追加する方法の詳細については、「Microsoft Entra ID (プレビュー)で外部認証方法を管理する」を参照してください。

Microsoft Entra ID とプロバイダーのやり取り

次のセクションでは、プロバイダーの要件について説明し、プロバイダーとの Microsoft Entra ID のやり取りの例を示します。

プロバイダー メタデータの検出

外部 ID プロバイダーは 、OIDC 検出エンドポイントを提供する必要があります。 このエンドポイントは、より多くの構成データを取得するために使われます。 完全な URL、well-known/oidc-configuration を含むURLは、EAMの作成時に設定されたディスカバリーURLに含まれている必要があります。

エンドポイントは、そこでホストされているプロバイダー メタデータ JSON ドキュメント を返します。 エンドポイントは、有効なコンテンツ長ヘッダーも返す必要があります。

次の表に、プロバイダーのメタデータに存在する必要があるデータを示します。 この機能拡張シナリオでは、これらの値が必要です。 JSON メタデータ ドキュメントにはさらに多くの情報が含まれる場合があります。

プロバイダー メタデータの値を含む OIDC ドキュメントについては、「 プロバイダー メタデータ」を参照してください。

http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

http://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

プロバイダー メタデータのキャッシュ

パフォーマンスを向上させるために、Microsoft Entra ID はキーなどの、プロバイダーから返されたメタデータをキャッシュします。 プロバイダー メタデータのキャッシュにより、Microsoft Entra ID が外部 ID プロバイダーと通信するたびに検出呼び出しが行われるのを防ぎます。

このキャッシュは 24 時間 (1 日) ごとに更新されます。 プロバイダーがキーをロールオーバーする方法は次のとおりです。

1. "jwks_uri" で 既存 の 証明書と新しい証明書 を発行します。
2. Microsoft Entra ID キャッシュが更新、期限切れ、または更新 (2 日ごと) になるまで、 既存の証明書 で署名を続けます。
3. 新しい証明書を使用した署名に切り替えます。

キーのロールオーバーのスケジュールは公開されません。 依存サービスは、即時ロールオーバーと定期ロールオーバーの両方を処理できるように準備する必要があります。 この目的のために構築された専用ライブラリ ( azure-activedirectory-identitymodel-extensions-for-dotnet など) を使用することをお勧めします。 詳細については、「 Microsoft Entra ID での署名キーのロールオーバー」を参照してください。

Microsoft Entra ID メタデータの検出

プロバイダーは、Microsoft Entra ID によって発行されたトークンを検証するために、Microsoft Entra ID の公開キーを取得する必要もあります。

Microsoft Entra ID メタデータの検出エンドポイント。

• グローバル Azure: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• 米国政府向け Azure: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• 21Vianet によって運営される Microsoft Azure: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

トークンの公開キー識別子 (JSON Web Signature (JWS) の "kid") を使用して、jwks_uri プロパティから取得したキーを Microsoft Entra ID トークン署名の検証に使用する必要があるかどうかを判断できます。

Microsoft Entra ID によって発行されたトークンの検証

Microsoft Entra ID によって発行されたトークンを検証する方法については、「 トークンの検証と ID」を参照してください。 検出メタデータの使用者に特別な手順はありません。

Microsoft の トークン検証ライブラリ には、文書化されているトークン検証の詳細に関するすべての詳細が含まれています。または、ソース コードの参照から確認できます。 サンプルについては、 Azure のサンプルを参照してください。

検証が成功すると、クレーム ペイロードを操作して、ユーザーとそのテナントの詳細を取得できます。

外部 ID プロバイダーへの Microsoft Entra ID 呼び出し

Microsoft Entra ID は 、OIDC 暗黙的フロー を使用して外部 ID プロバイダーと通信します。 このフローを使うと、プロバイダーとの通信は、プロバイダーの承認エンドポイントを使うことによってのみ行われます。 Microsoft Entra ID が要求を行っているユーザーをプロバイダーに知らせるために、Microsoft Entra ID は id_token_hint パラメーターを介してトークンを渡します。

プロバイダーに渡されるパラメーターのリストが大きいため、この呼び出しは POST 要求を通じて行われます。 大きなリストでは、GET 要求の長さを制限するブラウザーを使用できません。

認証要求のパラメーターを次の表に示します。

リダイレクト URI の例

リダイレクト Uniform Resource Identifier (URI) はプロバイダーのオフバンドに登録する必要があります。 送信できるリダイレクト URI は次のとおりです。

• グローバル Azure: https://login.microsoftonline.com/common/federation/externalauthprovider
• 米国政府向け Azure: https://login.microsoftonline.us/common/federation/externalauthprovider
• 21Vianet によって運営される Microsoft Azure: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

MFA を満たす EAM の例

EAM が MFA を満たす認証の例を次に示します。 この例は、Microsoft Entra ID で想定されるクレームが何かをプロバイダーが把握するのに役立ちます。

acr 値と amr 値の組み合わせは、Microsoft Entra ID によって以下を検証するために使われます。

• 2 番目の要素に使われる認証方法が MFA 要件を満たしている
• 認証方法は、Microsoft Entra ID へのサインインの最初の要素を完了するために使われる方法とは "種類" が異なる

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

既定の Id_token_hint クレーム

このセクションでは、プロバイダーへの要求で id_token_hint として渡されるトークンの必須コンテンツについて説明します。 トークンには、次の表よりも多くのクレームが含まれる場合があります。

ヒント以外に使われないように、トークンは期限切れとして発行されます。 トークンは署名されており、公開された Microsoft Entra ID 検出メタデータを使って検証できます。

Microsoft Entra ID からのオプションのクレーム

プロバイダーが Microsoft Entra ID からのオプションのクレームを必要とする場合は、オプションのクレーム (given_name、family_name、preferred_username、upn) を id_token に対して構成できます。 詳細については、「 省略可能な要求」を参照してください。

クレームの推奨される使用法

Microsoft では、oid と tid のクレームを使って、プロバイダー側のアカウントを Azure AD のアカウントに関連付けることをお勧めします。 これら 2 つのクレームは、テナント内のアカウントに対して一意であることが保証されています。

id_token_hint の例

ディレクトリ メンバーの id_token_hint の例を次に示します。

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

テナントのゲスト ユーザーの id_token ヒントの例を次に示します。

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

外部 ID プロバイダーに推奨される操作

外部 ID プロバイダーがこれらの手順を完了することをお勧めします。 この一覧はすべてを網羅しているわけではないため、プロバイダーは必要に応じて他の検証手順を完了する必要があります。

1. 要求から:
   • 外部 ID プロバイダーに対する Microsoft Entra ID 呼び出しでredirect_uriが公開されていることを確認します。
   • client_idに、 ABCD などの Microsoft Entra ID に値が割り当てられていることを確認します。
   • プロバイダーはまず、Microsoft Entra ID によって提示されるid_token_hintを 検証 する必要があります。
2. id_token_hint のクレームから:
   • 必要に応じて、 Microsoft Graph を呼び出して、このユーザーに関するその他の詳細をフェッチできます。 この点で、id_token_hintの oid 要求と tid 要求が役立ちます。 id_token_hintで提供される要求の詳細については、「 既定のid_token_hint要求」を参照してください。
3. 次に、プロバイダーの製品が行うように構築されている他の認証アクティビティを実行します。
4. 次のセクションで説明するように、ユーザーのアクションの結果やその他の要因に応じて、プロバイダーは応答を構築して Microsoft Entra ID に返します。

プロバイダー応答の Microsoft Entra ID 処理

プロバイダーは、応答を redirect_uriにポストバックする必要があります。 成功した応答では、次のパラメーターを指定する必要があります。

成功すると、プロバイダーはユーザーに id_token を発行します。 Microsoft Entra ID は、公開された OIDC メタデータを使って、トークンに予期されるクレームが含まれていることを確認し、OIDC が必要とするその他のトークンの検証を行います。

サポートされている acr クレーム

サポートされている amr クレーム

Microsoft Entra ID では、MFA クレームを含むトークンを発行するには MFA が満たされている必要があります。 その結果、別の種類の方法だけが 2 番目の要素の要件を満たすことができます。 前述したように、2 番目の要素を満たすために使用できる別の方法の種類は、知識、所有、固有性です。

Microsoft Entra ID は、次の表に基づいて種類のマッピングを検証します。

トークンに問題が見つからなかった場合、Microsoft Entra ID は MFA が満たされていると見なし、エンド ユーザーにトークンを発行します。 それ以外の場合、エンド ユーザーの要求は失敗します。

失敗は、エラー応答パラメーターの発行によって示されます。

Microsoft Entra ID は、応答に id_token パラメーターが存在し、トークンが有効な場合、要求が成功したと見なします。 それ以外の場合、要求は失敗したと見なされます。 Microsoft Entra ID は、条件付きアクセス ポリシーの要件により、元の認証試行に失敗します。

Microsoft Entra ID は、プロバイダーへのリダイレクトから約 5 分後に、認証試行の状態を破棄します。

Microsoft Entra ID エラー応答処理

Microsoft Azure サービスは、correlationId を使って、さまざまな内部および外部システム間で呼び出しを関連付けます。 これは、複数の HTTP 呼び出しが含まれる可能性がある操作またはフロー全体の共通の識別子として機能します。 いずれかの操作中にエラーが発生した場合、応答には Correlation ID というフィールドが含まれます。

Microsoft サポートまたは同様のサービスに連絡する場合は、テレメトリとログにすばやくアクセスするのに役立つため、この Correlation ID の値を提示してください。

次に例を示します。

ENTRA IDSTS70002: 資格情報の検証でエラーが発生しました。 ENTRA IDSTS50012: 発行者 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' からの外部 ID トークンが署名の検証に失敗しました。 トークンの KeyID が 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' トレース ID: 0000aaaa-11bb-cccc-dd22-eeeeee33333 3 関連付け ID: aaaa0000-bb11-2222-33cc-444444ddddddd タイムスタンプ: 2023-07-24 16:51:34Z

カスタム コントロールと EAM

Microsoft Entra ID では、顧客が EAM への準備と移行を行っている間、EAM と条件付きアクセスのカスタム コントロールを並行して動作させることができます。

現在、カスタム コントロールを使って外部プロバイダーとの統合を使っている顧客は、それらと、アクセスを管理するために構成した条件付きアクセス ポリシーを引き続き使用できます。 管理者は、移行期間中に条件付きアクセス ポリシーの並列セットを作成することをお勧めします。

• ポリシーでは、カスタム コントロールの許可ではなく、 多要素認証 許可コントロールを使用する必要があります。

  注

  組み込みの MFA 強度を含む認証強度に基づく許可制御は、EAM では満たされません。 ポリシーは、[ 多要素認証が必要] でのみ構成する必要があります。 認証強度を備えた EAM のサポートは、後で提供されます。

• 新しいポリシーは、最初にユーザーのサブセットを使ってテストできます。 テスト グループは、カスタム コントロールを必要とするポリシーから除外され、MFA を必要とするポリシーに含まれます。 管理者が MFA を必要とするポリシーが EAM によって満たされることを確認したら、管理者は MFA 許可を持つポリシーに必要なすべてのユーザーを含め、カスタム コントロール用に構成されたポリシーを オフに移動できます。

統合サポート

Microsoft Entra ID との EAM 統合を構築するときに問題が発生した場合は、Microsoft カスタマー エクスペリエンス エンジニアリング (CxE) の独立系ソリューション ベンダー (ISV) がサポートできる場合があります。 CxE ISV チームと連携するには、 サポートの要求を送信します。

関連情報

• OAuth2.0 と OIDC の仕様

用語集

次のステップ

Microsoft Entra 管理センターで EAM を構成する方法の詳細については、「Microsoft で外部認証方法を管理する (プレビュー)」を参照してください。