共用方式為

將 App Service 或 Azure Functions 應用程式設定為使用 Microsoft Entra 登入

選取以跳至其他驗證提供者。

本文說明如何設定 Azure App Service 或 Azure Functions 的驗證，讓您的應用程式使用 Microsoft 身分識別平台 (Microsoft Entra) 作為驗證提供者來登入使用者。

為您的應用程式及其使用者選擇租用戶

在應用程式可以讓使用者登入之前，您需要先將其註冊於員工租用戶或外部租用戶。 如果要將應用程式提供給員工或商務來賓使用，請在員工租用戶中註冊應用程式。 如果應用程式要給消費者和商務客戶使用，請在外部租用戶中註冊應用程式。

  1. 登入 Azure 入口網站 並移至您的應用程式。

  2. 在應用程式的左側功能表上，選取 [設定>驗證]，然後選取 [新增識別提供者]。

  3. 在 [ 新增識別提供者 ] 頁面上，選取 [Microsoft ] 作為 [ 識別提供者 ] 值，以登入Microsoft和Microsoft Entra 身分識別。

  4. 在 [為您的應用程式及其使用者選擇租使用者] 下，選取下列其中一項：

    • 員工和商務來賓的員工配置（目前租戶）
    • 消費者與商務客戶的外部設定

選擇應用程式註冊

App Service 驗證功能可以自動為您建立應用程式註冊。 或者，您可以使用您或目錄管理員個別建立的註冊。

若不需要個別建立應用程式註冊，請自動建立新的應用程式註冊。 您想要的話，可以在 Microsoft Entra 系統管理中心自訂應用程式註冊。

以下是使用現有應用程式註冊最常見的案例：

  • 您的帳戶沒有在 Microsoft Entra 租用戶中建立應用程式註冊的權限。
  • 您想要使用不同於包含您應用程式的 Microsoft Entra 租戶中的應用程式註冊。 如果您在選擇租用戶時選取外部組態，則總會發生這種情況。
  • 建立新註冊的選項不適用於政府雲端。

選項 1：建立並使用新的應用程式註冊

  1. 選取 [ 建立新的應用程式註冊]。

  2. 針對 [名稱]，輸入新應用程式註冊的名稱。

  3. 選取 支援的帳戶類型 值：

    • 目前租用戶 - 單一租用戶。 僅此組織目錄中的帳戶。 您目錄中的所有使用者及來賓帳戶都能使用您的應用程式或 API。 若您的目標對象是組織內部的人員，請使用此選項。
    • 任何 Microsoft Entra 目錄 - 多租用戶。 任何組織目錄中的帳戶。 所有使用者只要具備 Microsoft 提供的公司或學校帳戶，都能使用您的應用程式或 API。 這些帳戶包括使用 Office 365 的學校和企業。 若目標對象是商務界或教育界的客戶，且要啟用多租用戶的話，請使用此選項。
    • 任何 Microsoft Entra 目錄和個人 Microsoft 帳戶。 任何組織目錄中的帳戶和個人Microsoft帳戶（例如 Skype 或 Xbox）。 具有公司或學校帳戶或個人Microsoft帳戶的所有使用者都可以使用您的應用程式或 API。 其中包含使用 Office 365 的學校和企業，以及用來登入 Xbox 和 Skype 等服務的個人帳戶。 若要涵蓋最多種類的 Microsoft 識別，且要啟用多租用戶的話，請使用此選項。
    • 僅限個人 Microsoft 帳戶。 用於登入 Xbox 及 Skype 等服務的個人帳戶。 使用此選項可涵蓋最多種類的 Microsoft 身分識別。

您要的話，可以稍後再變更註冊的名稱或支援的帳戶類型。

用戶端密碼會建立為名為 的插槽黏性MICROSOFT_PROVIDER_AUTHENTICATION_SECRET。 如果您想要在 Azure 金鑰保存庫 中管理秘密，您可以稍後更新該設定，以使用 金鑰保存庫 參考。 或者，您可以將此變更為 使用身分識別，而不是客戶端密碼。 使用身分識別的支援目前為預覽狀態。

選項 2：個別使用已建立的現有註冊

若要使用現有的註冊，請選取下列其中一項：

  • 在此目錄中挑選現有的應用程式註冊。 然後從下拉式清單中選取應用程式註冊。

  • 提供現有應用程式註冊的詳細數據。 隨後提供：

    • 應用程式 （用戶端） 識別碼。

    • 用戶端密碼 （建議） 。 應用程式在要求令牌時用來證明其身分識別的秘密值。 此值會在應用程式的設定中儲存為名為 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET 的插槽黏性應用程式設定。 如果未設定用戶端密碼，來自服務的登入作業會使用 OAuth 2.0 隱含授與流程， 不建議 這麼做。

      您也可以將應用程式設定為 使用身分識別，而不是客戶端密碼。 使用身分識別的支援目前為預覽狀態。

    • 簽發者 URL。 此網址格式為 <authentication-endpoint>/<tenant-id>/v2.0。 將 <authentication-endpoint> 替換為適合雲端環境的 驗證端點值。 例如，全域 Azure 中的租戶會使用 https://sts.windows.net 作為其驗證端點。

如果您需要在員工租使用者中手動建立應用程式註冊，請參閱使用 Microsoft 身分識別平台 註冊應用程式。 完成註冊程序後，請務必記下應用程式 (用戶端) 識別碼和用戶端密碼值。

在註冊程序期間，在 [ 重新導向 URI] 區段中，選取 [Web for platform]，然後輸入重新導向 URI。 例如，輸入 https://contoso.azurewebsites.net/.auth/login/aad/callback。

現在，修改應用程式註冊：

  1. 在左窗格中，選取 [公開 API>新增>儲存]。 當應用程式作為資源使用時，此值能夠獨特地辨識該應用程式，並允許要求授予存取權的令牌。 值是您所建立之範圍的前置詞。

    針對單一租用戶應用程式，您可以使用預設值，其格式為 api://<application-client-id>。 您也可以根據租使用者的其中一個已驗證網域來指定更可讀取的 URI，例如 https://contoso.com/api。 對於多租用戶應用程式，您必須提供自訂 URI。 如需應用程式識別碼 URI 接受格式的詳細資訊，請參閱 Microsoft Entra ID 中應用程式屬性的安全性最佳做法。

  2. 選取 [新增範圍]，然後：

    1. 在 [範圍名稱] 中，輸入 user_impersonation。
    2. 在 [有權同意者]，如果您想要允許使用者同意此範圍，請選取 [管理員和使用者]。
    3. 輸入同意範圍名稱。 輸入您希望使用者在同意頁面上看到的描述。 例如，輸入 Accessapplication-name。
    4. 選取新增範圍。

  3. （建議）替應用程式建立用戶端聲明。 若要建立用戶端密碼：

    1. 在左窗格中，選取 [ 憑證與秘密>用戶端秘密] [用戶端密碼>][新增客戶端密碼]。
    2. 輸入描述和到期日，然後選取 [ 新增]。
    3. 在 [值] 欄位，複製用戶端密碼值。 離開此頁面之後，它就不會再次出現。

    您也可以將應用程式設定為 使用身分識別，而不是客戶端密碼。 使用身分識別的支援目前為預覽狀態。

  4. （選擇性）若要新增多個回復 URL，請選取 [ 驗證]。

設定其他檢查

其他檢查 會決定允許哪些要求存取您的應用程式。 您可以立即自定義此行為，或稍後從主要驗證頁面選取 [驗證設定] 旁的 [編輯] 來調整這些設定。

針對 [用戶端應用程式需求]，請選擇是否要：

  • 只允許來自此應用程式本身的要求。
  • 允許來自特定用戶端應用程式的要求。
  • 允許來自任何應用程式的要求（不建議）。

針對 [身分識別需求]，請選擇是否要：

  • 允許來自任何身份的要求。
  • 允許來自特定身份的要求。

針對 [租用戶需求]，請選擇是否要：

  • 只允許來自發行者租戶的請求。
  • 允許特定租戶的請求。
  • 根據簽發者使用預設限制。

您的應用程式可能仍然需要在程式碼中做出其他授權決策。 如需詳細資訊，請參閱本文稍後 的使用內建授權原則 。

設定驗證設定

驗證設定會決定您的應用程式如何回應未經驗證的要求。 預設選項會將所有要求改為使用此新的提供者登入。 您可以立即自定義此行為，或稍後從主要驗證頁面選取 [驗證設定] 旁的 [編輯] 來調整這些設定。 如需詳細資訊，請參閱驗證流程。

針對 [限制存取]，請決定是否要：

  • 需要驗證。
  • 允許未經驗證的存取。

針對 [未驗證的要求]，選擇錯誤選項：

  • HTTP 302 Found redirect：建議用於網站
  • HTTP 401 Unauthorized：建議用於 API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

選取 [權杖存放區] (建議使用)。 權杖存放區會收集、儲存及重新整理應用程式的權杖。 如果您的應用程式不需要令牌，或需要優化效能，您可以稍後停用此行為。

新增識別提供者

如果您選取了員工設定，您可以選取 [ 下一步：許可權 ]，並新增應用程式所需的任何Microsoft Graph 許可權。 這些許可權會新增至應用程式註冊，但您也可以稍後加以變更。 如果選取了外部設定，您後續可以新增 Microsoft Graph 權限。

  • 選取 [新增]。

您現在已準備好在應用程式中使用 Microsoft 身分識別平台進行驗證。 提供者會列在 [ 驗證 ] 頁面上。 您可以從這裡編輯或刪除此提供者設定。

如需為存取 Azure 儲存體 和 Microsoft Graph 的 Web 應用程式設定 Microsoft Entra 登入的範例，請參閱將應用程式驗證新增至您的 Web 應用程式。

授權要求

根據預設，App Service 驗證只會處理 驗證。 它會判斷來電者是否為他們所說的人。 授權，判斷該呼叫端是否應該具有某些資源的存取權，是驗證以外的步驟。 如需詳細資訊，請參閱 授權基本概念。

您的應用程式可以以程式碼進行授權決策。 App Service 驗證提供一些 內建檢查，可協助，但僅此檢查可能不足以涵蓋您應用程式的授權需求。 下列各節涵蓋這些功能。

提示

多租使用者應用程式應該在此程式中驗證要求的簽發者和租使用者標識碼，以確保允許這些值。 當 App Service 驗證設定為多租戶情境時，系統不會驗證請求來自哪個租戶。 根據組織是否已註冊服務，應用程式可能需要限制為特定租使用者（例如）。 請參閱 更新程式代碼以處理多個簽發者值。

從應用程式程式碼執行驗證

當您在應用程式程式代碼中執行授權檢查時，可以使用App Service驗證所提供的宣告資訊。 如需詳細資訊，請參閱 存取應用程式程式代碼中的使用者宣告。

插入的 x-ms-client-principal 標頭包含 Base64 編碼的 JSON 物件，其中已插入有關呼叫者的宣告。 根據預設，這些宣告會經過宣告對應，因此宣告名稱不一定符合您在令牌中看到的內容。 例如，tid 宣告會改為對應至 http://schemas.microsoft.com/identity/claims/tenantid。

您也可以直接使用所插入 x-ms-token-aad-access-token 標頭的基礎存取權杖。

使用內建授權原則

已建立的應用程式註冊會驗證 Microsoft Entra 租用戶的連入要求。 根據預設，它也會讓租使用者內的任何人存取應用程式。 這種方法適用於許多應用程式。 某些應用程式需要藉由做出授權決策來進一步限制存取。

您的應用程式的程式碼通常是處理自訂授權邏輯的最佳位置。 然而，若是常見的案例，Microsoft 身分識別平台提供一些內建檢查，您可以用來限制存取。

本節說明如何使用 App Service驗證 V2 API 來啟用內建檢查。 目前，設定這些內建檢查的唯一方式是使用 Azure Resource Manager 範本 或 REST API。

在 API 物件中，Microsoft Entra 識別提供者組態具有 validation 可包含 defaultAuthorizationPolicy 物件的區段，如下列結構所示：

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
屬性 說明
defaultAuthorizationPolicy 必須符合才能存取應用程式的需求群組。 會針對其每個設定的屬性，根據邏輯 AND 來授與存取權。 當 allowedApplications 和 allowedPrincipals 都已設定時，傳入要求必須同時滿足兩項要求才能被接受。
allowedApplications 字串應用程式 用戶端識別碼 的允許清單，代表呼叫應用程式的客戶端資源。 當此屬性設定為無空陣列時，只會接受清單中指定之應用程式的令牌。

此原則會評估傳入權杖 (必須是存取權杖) 的 appid 或 azp 宣告。 請參閱 承載宣告。
allowedPrincipals 一組檢查，判斷傳入要求所代表的主體是否可以存取應用程式。 是否滿足 allowedPrincipals 會針對其已設定的屬性，根據邏輯 OR 來決定。
identities (在 allowedPrincipals 之下) 字串 物件識別碼 的允許清單，代表具有存取權的使用者或應用程式。 當這個屬性設定為無空陣列時，如果清單中指定了要求所代表的使用者或應用程式， allowedPrincipals 就可以滿足需求。 身分識別清單的限制為500個字元（總計）。

此原則會評估傳入權杖的 oid 宣告。 請參閱 承載宣告。

此外，不論您使用的 API 版本為何，您都可以透過 應用程式設定來設定一些檢查。 您可以使用 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 最多 10 個租使用者識別碼的逗號分隔清單來設定應用程式設定，例如 aaaabbbb-0000-cccc-1111-dddd2222eeee。 此設定可能會要求傳入令牌來自其中一個指定的租使用者，如宣告所 tid 指定。

您可以將 WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL 應用程式設定為 true 或 1，以要求傳入令牌包含 oid 宣告。 如果您已設定 allowedPrincipals.identities，則會忽略此設定，並視為 true，因為會將 oid 宣告與此提供的身分識別清單進行核對。

這些內建檢查失敗的要求會取得 HTTP 403 Forbidden 回應。

使用受控識別而非秘密 （預覽）

您可以設定 應用程式以信任受控識別（預覽），而不是設定應用程式註冊的客戶端密碼。 使用身分識別而非秘密表示您不需要管理秘密。 您沒有要處理的秘密到期事件，而且您沒有與可能公開或洩漏該秘密相關聯的相同層級風險。

身分識別可讓您建立 同盟身分識別認證，此認證可用來取代客戶端密碼作為 客戶端判斷提示。 此方法僅適用於人力配置。 內建驗證功能目前支援聯邦身分識別憑證作為預覽版本。

您可以使用本節中的步驟來設定 App Service 或 Azure Functions 資源以使用此模式。 此處的步驟假設您已使用其中一個支援的方法來設定應用程式註冊，而且您已定義秘密。

  1. 根據這些指示建立使用者指派的受控識別資源。

  2. 將該身分識別指派 給 App Service 或 Azure Functions 資源。

    這很重要

    您建立的使用者指派受控識別只能透過此註冊指派給 App Service 或 Azure Functions 應用程式。 如果您將身分識別指派給另一個資源，您會提供該資源不必要的應用程式註冊存取權。

  3. 記下受控識別的物件 標識碼 和 用戶端 標識碼。 在下一個步驟中，您將需要對象標識碼來建立同盟身分識別認證。 您將在稍後的步驟中使用受控識別的用戶端識別碼。

  4. 請遵循Microsoft Entra ID 指示，在現有的應用程式上設定同盟身分識別認證。 這些指示也包含更新應用程式程式碼的區段，您可以略過這些程式碼。

  5. 新增名為 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID。 將其值設定為您在上一個步驟中取得的受控識別 用戶端標識碼 值。 請勿使用應用程式註冊的用戶端識別碼。 請務必將此應用程式設定標示為插槽固定。

  6. 在應用程式資源的內建驗證設定中，將 [客戶端密碼] 設定名稱 設定為 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID。

    若要使用 Azure 入口網站進行這項變更：

    1. 返回您的 App Service 或 Azure Functions 資源，然後選取 [ 驗證] 索引標籤。
    2. 在 [ 識別提供者 ] 區段中，針對 [Microsoft ] 項目，選取 [編輯 ] 數據行中的圖示。
    3. 在 [ 編輯識別提供者] 對話框中，開啟 [用戶端密碼設定名稱 ] 的下拉式清單，然後選取 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID。
    4. 選取 [儲存]。

    若要使用 REST API 進行這項變更：

    • 將 clientSecretSettingName 屬性設定為 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID。 您可以在 下properties>identityProviders>azureActiveDirectory>registration找到這個屬性。

  7. 確認應用程式如預期般運作。 您應該能夠順利執行新的登入動作。

當您滿意使用受控識別的行為時，請移除現有的秘密：

  1. 請確定您的應用程式程式代碼不會相依於應用程式設定。 如果這樣做，請遵循 指示來更新應用程式程式碼以要求存取令牌。

  2. 拿掉先前保存秘密的應用程式設定。 這個應用程式設定的名稱是先前的 客戶端密碼設定名稱 值，再將它設定為 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID。

  3. 使用包含應用程式註冊的租戶，登入 Microsoft Entra 系統管理中心。 再次移至應用程式註冊。

  4. 在 [憑證與秘密] 底下，選取 [用戶端密碼 ]，然後移除客戶端密碼。

您的應用程式現在已設定為不使用秘密Microsoft Entra ID 驗證。

設定用戶端應用程式以存取 App Service 平台

在先前各節中，您已註冊 App Service 或 Azure Functions 應用程式來驗證使用者。 下列各節說明如何在 Microsoft Entra 中註冊原生用戶端或精靈應用程式。 這些用戶端或應用程式可以要求存取 App Service 代表使用者或本身公開的 API，例如在多層式架構中。 如果您只想要驗證使用者，則不需要下列各節中的步驟。

原生用戶端應用程式

您可以註冊原生用戶端，以代表登入的使用者要求存取 App Service 應用程式的 API：

  1. 在 Azure 入口網站的選單上，選取 Microsoft Entra ID。

  2. 在左窗格中，選取 [ 管理>應用程式註冊]。 然後選取 [新增註冊]。

  3. 在 [ 註冊應用程式] 窗格的 [ 名稱] 中，輸入應用程式註冊的名稱。

  4. 在 [重新導向 URI] 中，選取 [公用用戶端/原生 ] [行動裝置和桌面]， 然後輸入重新導向 URL。 例如，輸入 https://contoso.azurewebsites.net/.auth/login/aad/callback。

  5. 選取註冊。

  6. 建立應用程式註冊之後，複製 [應用程式 (用戶端) 識別碼] 的值。

    注意

    若是 Microsoft Store 應用程式，請改為使用套件 SID作為 URI。

  7. 在左窗格中，選取 [ 管理>API 許可權]。 然後選取 [ 新增許可權>我的 API]。

  8. 選取您稍早為 App Service 應用程式建立的應用程式註冊。 如果您沒有看到應用程式註冊，請務必在應用程式註冊中新增 user_impersonation 範圍。

  9. 在 [委派權限] 底下，選取 [user_impersonation]，然後選取 [新增權限]。

您現在已設定原生用戶端應用程式，可代表使用者要求存取 App Service 應用程式。

精靈用戶端應用程式 (服務對服務呼叫)

在多層式架構中，用戶端應用程式可以取得令牌，代表用戶端應用程式本身呼叫 App Service 或 Azure Functions 應用程式，而不是代表使用者。 此案例適用於執行沒有登入使用者之工作的非互動式精靈應用程式。 其會使用標準 OAuth 2.0 用戶端認證授與。 如需詳細資訊，請參閱 Microsoft 身分識別平台 和 OAuth 2.0 用戶端認證流程。

  1. 在 Azure 入口網站的選單上，選取 Microsoft Entra ID。

  2. 在左窗格中，選取 [ 管理>應用程式註冊]。 然後選取 [新增註冊]。

  3. 在 [ 註冊應用程式] 窗格的 [ 名稱] 中，輸入應用程式註冊的名稱。

  4. 針對精靈應用程式，您不需要重新導向 URI，因此您可以將 [ 重新導向 URI ] 方塊保留空白。

  5. 選取註冊。

  6. 建立應用程式註冊之後，複製 [應用程式 (用戶端) 識別碼] 的值。

  7. 在左窗格中，選取 [管理>憑證與秘密]。 然後選取 [客戶端密碼>] [新增客戶端密碼]。

  8. 輸入描述和到期日，然後選取 [ 新增]。

  9. 在 [值] 欄位，複製用戶端密碼值。 離開此頁面之後，它就不會再次出現。

您現在可以使用 用戶端識別碼和客戶端密碼來要求存取令牌。 將 resource 參數設定為目標應用程式 的應用程式識別碼 URI 值。 然後，產生的存取令牌可以透過標準 OAuth 2.0 授權標頭呈現給目標應用程式。 App Service 驗證會驗證並使用令牌來顯示呼叫端已驗證。 在此情況下，呼叫端是應用程式，而不是使用者。

此方法可讓 Microsoft Entra 租使用者中的任何用戶端應用程式要求存取令牌，並向目標應用程式進行驗證。 如果您也想要強制授權只允許特定用戶端應用程式，您必須執行額外的設定。

  1. 在應用程式註冊資訊清單中定義應用程式角色，代表您想要保護的 App Service 或 Azure Functions 應用程式。

  2. 在代表需要授權之用戶端的應用程式註冊上，選取 >我的 API]。

  3. 選取您稍早建立的應用程式註冊。 如果您沒有看到應用程式註冊，請確定您已 新增應用程式角色。

  4. 在 [應用程式許可權] 底下，選取您稍早建立的應用程式角色。 然後選取 [新增權限]。

  5. 選取 [授與管理員同意 ] 以授權用戶端應用程式要求許可權。

    類似於先前的案例（新增任何角色之前），您現在可以要求相同目標資源的 存取令牌 。 存取令牌包含 roles 宣告，其中包含為用戶端應用程式授權的應用程式角色。

在目標 App Service 或 Azure Functions 應用程式程式代碼內，您現在可以驗證令牌是否具有預期的角色。 App Service 驗證不會執行此驗證。 如需詳細資訊，請參閱 存取應用程式程式代碼中的使用者宣告。

您現在已設定精靈用戶端應用程式，其可以使用自己的身分識別來存取 App Service 應用程式。

最佳作法

無論您用來設定驗證的組態為何，下列最佳做法都會讓您的租用戶和應用程式更安全：

  • 在 Microsoft Entra 中設定每個 App Service 應用程式及其本身的應用程式註冊。
  • 為每個 App Service 應用程式提供其自己的權限並予以同意。
  • 避免在環境之間共享許可權。 針對不同的部署位置使用個別的應用程式註冊。 當您測試新的程式碼時，這種做法有助於防止問題影響生產應用程式。

遷移至 Microsoft Graph

某些較舊的應用程式可能依賴 Azure AD Graph，因為 Azure AD Graph 正被淘汰並計畫全面停止服務。 例如，您的應用程式程式代碼可能會呼叫 Azure AD Graph，以在中間件管線中檢查群組成員資格作為授權篩選的一部分。 應用程式應該移至 Microsoft Graph。 如需詳細資訊，請參閱 將您的應用程式從 Azure AD Graph 遷移至 Microsoft Graph。

在此移轉期間，您可能需要對 App Service 驗證的設定進行一些變更。 將Microsoft Graph 許可權新增至應用程式註冊之後，您可以：

  • 更新 簽發者 URL 值，以包含 /v2.0 後綴（如果尚未包含）。

  • 從您的登入組態中移除 Azure AD Graph 權限的要求。 要變更的屬性取決於您使用的管理 API 版本：

    • 如果您使用 V1 API （/authsettings），則此設定位於陣列中 additionalLoginParams 。
    • 如果您使用 V2 API （/authsettingsV2），則此設定位於陣列中 loginParameters 。

    例如，您需要移除 對 的任何參考 https://graph.windows.net。 這項變更包含resource/v2.0端點不支持的參數。 它也包含您特別要求來自 Azure AD Graph 的任何範圍。

    您也需要更新組態，以要求您為應用程式註冊設定的新Microsoft Graph 許可權。 在許多情況下，您可以使用 預設範圍 來簡化此設定。 若要這樣做，請新增登入參數： scope=openid profile email https://graph.microsoft.com/.default。

使用這些變更時，當 App Service 驗證嘗試登入時，它就不會再要求 Azure AD Graph 的許可權。 相反地，它會取得 Microsoft Graph 的令牌。 您應用程式程式代碼的任何使用該令牌也需要更新，如將應用程式從 Azure AD Graph 遷移至 Microsoft Graph 中所述。

相關內容