使用 Microsoft Entra 多重因素驗證與外部供應商（預覽版）

本文說明外部認證提供者如何連接 Microsoft Entra 多重驗證（MFA）。

當使用者登入時，會評估租用戶原則。 驗證需求是根據使用者嘗試存取的資源來決定。

根據其參數，登入可能會有多個政策。 這些參數包括使用者與群組、應用程式、平台、登入風險等級等。

根據驗證要求，使用者可能需要以其他因素登入以符合多重身份驗證（MFA）要求。 第二個因素的類型需要與第一個因素的類型相輔相成。

租戶管理員會為 Microsoft Entra ID 新增外部認證方法。 若租戶需要外部驗證 MFA 方式，則在 Microsoft Entra ID 驗證兩者後，登入即視為符合 MFA 要求：

• 第一個步驟是使用 Microsoft Entra ID 完成的。
• 第二個因素是透過外部認證方法完成的。

該驗證符合兩種或以上方法的多重因素驗證要求：

• 您已知的資訊 (知識)
• 您擁有的物品 (持有)
• 您的某些特徵 (固有)

外部認證方法則實作於 OpenID Connect（OIDC）之上。 此實作至少需要三個面向公眾的端點來實作外部認證方法：

• OIDC 探索端點，如探索提供者元數據中所述
• 有效的 OIDC 驗證端點
• 發佈提供者公開憑證所在的 URL

以下是使用外部認證方式登入的運作方式：

1. 使用者嘗試使用密碼等第一個因素登入受 Microsoft Entra ID 保護的應用程式。

2. Microsoft Entra ID 會判斷需要滿足其他因素（例如條件存取政策是否需要多重驗證）。

3. 使用者選擇外部認證方式作為第二因素。

4. Microsoft Entra ID 會將使用者的瀏覽器會話重新導向到外部驗證方法的網址。

   這個 URL 是從管理員在建立外部認證方法時設定的發現 URL 中發現的。

   應用程式會提供即將過期或已過期的憑證，其中包含識別使用者和租戶的資訊。

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

要發出 id_token_hint，外部認證方法需要一個能代表整合的應用程式。 你可以用兩種方式建立應用程式：

• 在每個使用外部供應商的租戶中。
• 作為一個多租戶應用程式。 為了讓租戶能夠整合，特權角色管理員需要授權同意。

使用多租戶應用程式可以降低每個租戶間錯誤設定的機率。 提供者也可以對元資料進行變更（例如，回覆網址集中於一處），而不必要求每個租戶都自行更改。

若要設定多租用戶應用程式，提供者管理員必須先：

1. 建立一個 Microsoft Entra ID 租戶（如果他們還沒有的話）。

2. 在其租用戶中註冊應用程式。

3. 在應用程式中，於支援帳號類型中，選擇任一組織目錄中的帳號（任一 Microsoft Entra ID 租戶 - 多租戶）。

4. 新增 Microsoft Graph 的委派權限 openid 與 profile 值。

5. 請勿在此應用程式中發佈任何範圍。

6. 將外部身份提供者的有效 authorization_endpoint 網址加入該應用程式作為回覆網址。

   注意

   在應用程式註冊中，將提供者的發現文件中所提供的authorization_endpoint值作為重新導向 URL。 否則，會出現以下錯誤：「ENTRA IDSTS50161：未能驗證外部理賠提供者的授權網址！」

應用程式註冊程序會建立具有數個屬性的應用程式。 你需要這些房產來配合我們的情境。

另一個有效的整合支援模式是為每個租戶使用一個應用程式。 如果您使用單一租用戶註冊，則租用戶系統管理員必須針對單一租用戶應用程式，使用上表中的屬性建立應用程式註冊。

設定選擇性宣告

提供者可透過使用 選用宣稱 id_token來配置更多宣稱。

為 Microsoft Entra ID 新增外部認證方法

外部身份提供者資訊會儲存在每個租戶的認證方法政策中。 提供者資訊被儲存為一種externalAuthenticationMethodConfiguration類型的驗證方法。

每個提供者在政策的列表物件中都有一個條目。 每個項目都必須陳述：

• 如果該方法已啟用。
• 包含的群組可以使用此方法。
• 排除的群體無法使用該方法。

要設定使用者登入的多重驗證要求，擁有條件存取管理員角色的使用者可以用「要求多重驗證授權」建立政策。 目前不支援具備驗證強度的外部驗證方法。

了解更多關於如何在 Microsoft Entra 管理中心 新增外部驗證方法 。

Microsoft Entra ID 與提供者的互動

接下來的章節將說明提供者需求，並包含 Microsoft Entra ID 如何與提供者互動的範例。

探索提供者中繼資料

外部識別提供者必須提供 OIDC 探索端點。 此端點可用來取得更多組態資料。

發現網址 必須 使用該 https 方案，且 結尾必須 為 /.well-known/openid-configuration。 你不能在這個段之後加入任何額外的路徑段、查詢字串或片段。 完整的發現網址必須包含在你建立外部驗證方法時設定的發現 URL 中。

端點會回傳一個託管於該處的提供者元資料 JSON 文件 。 端點還必須回傳有效的內容長度標頭。 元資料文件 必須 符合 OpenID Connect Discovery 1.0 （包含勘誤集 2），並包含所有必要的 OIDC 元資料欄位。

提供者的元資料必須包含下表中列出的資料。 此擴充性案例需要這些值。 JSON 元資料文件可能包含更多資訊。

關於包含提供者元資料值的 OIDC 文件，請參見 提供者元資料。

https://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/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

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

發現網址與發行者範例

以下範例說明此整合中有效與無效的發現 URL 及發行者組合。

有效的探索網址和發行者配對

• 探索 URL：https://example.com/.well-known/openid-configuration
  發行人： https://example.com
• 探索 URL：https://example.com:8443/.well-known/openid-configuration
  發行人： https://example.com:8443
• 探索 URL：https://example.com/tenant1/.well-known/openid-configuration
  發行人： https://example.com/tenant1

無效的發現網址與發行者範例

• 探索 URL：https://example.com/.well-known/openid-configuration
  發行者： https://example.com:443/ （發行者中明確新增預設 HTTPS 埠口。）
• 探索 URL：https://example.com:443/.well-known/openid-configuration
  發行商： https://example.com/ （埠口不匹配。）
• 探索 URL：https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  發行者： https://example.com （你不能在發現網址中包含查詢字串。）

提供者中繼資料快取

為了提升效能，Microsoft Entra ID 會快取提供者回傳的元資料，包括金鑰。 提供者元資料快取防止每次 Microsoft Entra ID 與外部身份提供者通訊時產生發現呼叫。

此快取每 24 小時刷新一次。 我們建議醫療提供者依以下步驟完成轉讓鑰匙：

1. 將 現有證書 與 新證書 發佈於 jwks_uri。
2. 持續用 現有憑證 登入，直到 Microsoft Entra ID 快取被刷新、過期或更新（每兩天一次）。
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 範例。

驗證成功後，你可以處理理賠有效載荷，取得使用者及其租戶的詳細資訊。

Microsoft Entra ID 致電外部識別提供者

Microsoft Entra ID 會使用 OIDC 隱含流程 與外部識別提供者通訊。 使用此流程時，與提供者的通訊僅使用提供者的授權端點進行。

為了通知提供者某個特定使用者的請求，Microsoft Entra ID 會透過參數 id_token_hint 傳遞一個令牌。

此呼叫是透過 POST 請求進行，因為會傳遞大量參數給提供者。 龐大的清單會防止使用限制請求長度 GET 的瀏覽器。

認證請求參數列於下表。

重定向 URI 範例

重定向 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）的外部認證方法範例

這裡有一個外部驗證方法符合多重身份驗證（MFA）要求的例子。 此範例可幫助供應者了解 Microsoft Entra ID 所預期的宣告。

Microsoft Entra ID 使用acr值及amr值的組合來驗證：

• 第二個因素所用的認證方法符合多重身份驗證（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 取得可選的宣告，你可以設定以下可選的宣告：id_token、given_name、family_name、preferred_username、upn。 如需詳細資訊，請參閱 選擇性宣告。

建議使用主張

我們建議你在 Azure 中使用 oid and tid 聲明，將提供者端的帳號與帳號關聯起來。 這兩個聲明保證對於租用戶中的帳戶來說是獨一無二的。

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

{
  "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"
  }.

對外部身份提供者的建議行動

我們建議外部身份提供者完成以下事項。 此清單並不詳盡，且提供者應該在其認為適合時完成其他驗證步驟。

• 摘自請求：

  • 請確保 redirect_uri 已按 Microsoft Entra ID 呼叫外部身份提供者 中的描述發佈。
  • 確保設定的發現 URL 使用 HTTPS，且結尾為 /.well-known/openid-configuration。 也要確保它不包含查詢參數或片段識別碼。 確保發行人的價值與證據披露文件完全一致。
  • 確保 有 client_id 給 Microsoft Entra ID 指派的值，例如 ABCD。
  • 提供者應先 驗證 Microsoft Entra ID 所呈現的資訊 id_token_hint 。

• 摘自以下聲明 id_token_hint：

  • （可選）打電話給 Microsoft Graph ，查詢該使用者的其他細節。 oid tid與 的id_token_hint主張在這方面非常有用。 id_token_hint所提供的宣告詳情，請參見 預設id_token_hint宣告。

• 執行服務提供者產品的其他認證活動。

• 根據使用者行為的結果及其他因素，提供者會建立並回傳回應給 Microsoft Entra ID，詳見下一節說明。

Microsoft Entra ID 對提供者回應的處理

提供者需要使用 POST 來回傳回應給 redirect_uri。 應該在成功的回應上提供下列參數：

成功後，提供者會為使用者發出 id_token 一個數值。 Microsoft Entra ID 利用已公布的 OIDC 元資料驗證令牌是否包含預期權利要求，並執行 OIDC 要求的其他令牌驗證。

支援的 ACR 聲明

支援的 amr 聲明

Microsoft Entra ID 要求 MFA 必須滿意才能發行帶有 MFA 主張的令牌。 因此，只有具有不同類型的方法才能滿足第二個因素需求。 如先前所述，可用來滿足第二個因素的不同方法類型是知識、擁有和固有。

Microsoft Entra ID 會根據下表檢查類型映射。

Microsoft Entra ID 認為當令牌沒有問題時，MFA 就已滿足，然後會向使用者發放此令牌。 否則，使用者的請求將失敗。

失敗會以發出錯誤回應參數來表示。

Microsoft Entra ID 若在回應中有 id_token parameter 且令牌有效，則視為請求成功。 否則，要求會被視為失敗。 Microsoft Entra ID 因條件存取政策的要求而未能通過原始驗證嘗試。

Microsoft Entra ID 會在將用戶重新導向至提供者後大約 5 分鐘，捨棄其端的驗證嘗試狀態。

Microsoft Entra ID 錯誤回應處理

Microsoft Azure 服務使用一個 correlationId 值來關聯各種內部與外部系統間的通話。 它可用作整個作業或流程的通用識別碼，這些識別碼可能牽涉到多個 HTTP 呼叫。 當任何操作發生錯誤時，回應中會包含一個名為 Correlation ID 的欄位。

當你聯絡 Microsoft 支援或類似服務時，請提供 相關 ID 值。 這有助於更快存取遙測數據和日誌。

例如：

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

自訂控制與外部認證方法

在 Microsoft Entra ID 中，外部認證方法與條件存取自訂控制可同時運作，讓客戶準備並遷移至外部驗證方法。

目前使用自訂控制項與外部提供者整合的客戶可以繼續使用它們，以及他們設定用來管理存取的任何條件式存取原則。 我們建議管理員在遷移期間建立一套平行的條件存取政策：

• 政策應該使用需要多重要素驗證的授權控制，而不是自訂控制。

  注意

  基於包括內建多因素驗證強度在內的認證強度設定，授權控制無法由外部驗證方法滿足。 原則應該只使用 [需要多重要素驗證] 來設定。

• 新的原則可以先使用使用者子集進行測試。 測試群組被排除在需要自訂控制的政策之外，並包含在需要多重驗證的政策中。 當管理員確定需要多重身份驗證的政策已透過外部驗證方式達成時，管理員即可將所有必要使用者納入多重認證授權。 自訂控制的政策可以移到 關閉 設定。

整合支援

如果你在與 Microsoft Entra ID 建立外部驗證方法整合時遇到問題，Microsoft 客戶體驗工程（CxE）獨立解決方案供應商（ISV）可能能協助你。 若要與 CxE ISV 小組互動，請提交 協助要求。

參考資料

• OAuth2.0 和 OIDC 規格

詞彙

相關內容

• 欲了解更多如何在 Microsoft Entra 管理中心設定外部認證方法的資訊，請參閱「 在 Microsoft 管理外部認證方法（預覽版）」。