共用方式為

使用 Microsoft Entra ID 授權應用程式、資源和工作負載

在本文中，我們將討論當個人與應用程式互動並引導應用程式時，應用程式開發介面 (API) 對使用者採取行動時的授權。 我們也會說明應用程式或服務獨立運作的時機。 這是一系列文章中的第四篇，說明獨立軟體開發人員 (ISV) 如何建置適用於 Microsoft Entra ID 的應用程式並將其最佳化。 在此系列中，您可以深入了解下列主題：

應用程式中的授權

在本節中，我們將討論個人與應用程式互動並引導應用程式的案例。 資源 (API) 中的授權一節描述當使用者需要授權才能存取資源，但 Microsoft Entra ID 未執行最終授權時，API 如何執行授權。 工作負載中的授權一節涵蓋應用程式或服務獨立運作的案例。

當應用程式需要存取使用者的資源時，需要下列授權。

  • 應用程式必須具有授權，才能存取目前使用者特定資源內的特定作業。
  • 使用者必須具有授權，才能在符合目前條件的情況下存取資源。
  • 使用者必須具有授權，才能存取資源。

授權流程從應用程式開始，該應用程式使用 OAuth 2.0，向 Microsoft Entra ID 要求存取權杖，以存取使用者特定資源內的特定作業。 在委派存取中，應用程式會作為使用者的委派。

對於開發人員來說，資源可以是 API，例如 Microsoft Graph、Azure 儲存體或自己的 API。 不過，大部分的 API 都具有各種作業，例如讀取和寫入。 當應用程式只會從 API 讀取時，應用程式就應該只具有讀取作業的授權。 這種方法可保護應用程式免於遭到入侵，並防止其使用比開發人員預期還多的存取。 當開發人員的應用程式只會針對所需作業進行授權時，開發人員會遵循最低權限的準則。

若要在特定 API 中指定應用程式需要哪些特定作業，開發人員會使用 OAuth 2.0 要求的範圍參數。 API 設計師會發佈應用程式可要求的範圍，作為 API 應用程式註冊的一部分。 例如，Microsoft Power BI 服務範圍包含下列項目。

Power BI 服務範圍 業務
https://analysis.windows.net/powerbi/api/Capacity.Read.All 應用程式可以檢視已登入使用者有權存取的所有 Power BI Premium 和 Power BI Embedded 容量。
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 應用程式可以檢視和編輯已登入使用者有權存取的所有 Power BI Premium 和 Power BI Embedded 容量。

如果應用程式只會讀取容量，應用程式就會要求 https://analysis.windows.net/powerbi/api/Capacity.Read.All 範圍。 如果應用程式會編輯容量，則應用程式會要求 https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 範圍。

範圍包含 API 的身分識別和作業的身分識別。 在 https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 範圍中，API 為 https://analysis.windows.net/powerbi/api。 作業為 Capacity.ReadWrite.All。 鑒於 Microsoft Graph API 的廣泛觸達和受歡迎程度，開發人員可以在沒有範圍 API 元件的情況下，要求 Microsoft Graph 的範圍。 例如，Microsoft Graph 會定義 https://graph.microsoft.com/Files.Read 的範圍，應用程式可以使用 Files.Read (而不是使用完整範圍名稱) 來提出要求。

若要完成第一個授權，應用程式必須具有授權才能存取目前使用者特定資源內的特定作業，Microsoft Entra ID 必須先驗證目前的使用者。 單一登入 (SSO) 可以滿足此驗證，也可能需要全新的使用者互動。

當 Microsoft Entra ID 判斷使用者之後，即會檢查該使用者是否已授權應用程式取得要求的範圍。 此流程稱為授與同意。 如果使用者已授與同意，授權流程就能繼續。 管理員同意可讓管理員使用者為自己和整個組織做出同意。 Microsoft Entra ID 會檢查應用程式是否已針對範圍取得管理員同意。 如果已授與，授權流程就會繼續。

在範圍設計期間，API 設計師可以指定只有管理員可同意的範圍。 需要管理員同意的範圍，代表 API 設計師認為更敏感、更強大或更廣泛的作業，以致於非管理員的使用者不應具有授與應用程式的授權單位。

雖然 API 設計師對哪些範圍需要管理員同意具有優先發言權，但他們沒有最終決定權。 當 API 設計師指定某個範圍需要管理員同意時，則該範圍一律需要管理員同意。 對於 API 設計師未指定為需要管理員同意的範圍，租用戶管理員可以要求管理員同意，或者以風險為基礎的升級同意可能會判斷管理員同意需求。 開發人員無法預測權杖要求是否需要管理員同意。 不過，此限制不會影響所需的程式碼。 拒絕同意只是拒絕權杖要求的許多原因之一。 應用程式一律必須正常處理未收到權杖的情況。

如果使用者或管理員尚未授與同意，使用者就會看到同意提示，如下列範例所示。

使用者同意提示的螢幕擷取畫面。

管理員使用者同意提示可能允許他們選取 [代表您的組織同意]，以便為租用戶中的所有使用者授與同意，如下列範例所示。

管理員同意提示的螢幕擷取畫面。

應用程式會控制出現使用者同意提示的時機。 Microsoft Entra ID 支援靜態同意：當應用程式使用 .default 範圍時，應用程式會要求已在 App 註冊中宣告的所有權限。 使用靜態同意，您的應用程式會事先要求其可能需要的所有權限。

靜態同意可能導致使用者和管理員不核准您應用程式的存取要求。 同意要求流程的最佳做法是在應用程式啟動時，於應用程式中動態要求基準功能的必要權限，並在需要時要求更多範圍。 當應用程式執行需要那些範圍的作業時，以累加方式要求更多範圍。 這種方法可讓使用者進一步了解與功能時機相互關聯的其他權限。 針對每個 API 存取權杖，Microsoft Entra ID 包含先前已授與應用程式的所有範圍，而不只是要求中的範圍。

例如，應用程式可以要求 https://graph.microsoft.com/user.read 登入使用者，並在應用程式啟動時存取使用者的設定檔。 稍後，使用者會選取 [儲存至 OneDrive]，而應用程式會要求 https://graph.microsoft.com/files.readwrite，將檔案寫入至使用者的 OneDrive。 由於使用者了解應用程式要求寫入至其 OneDrive 的原因，因此，使用者會授與權限，而該應用程式會將檔案儲存至使用者的 OneDrive。 使用者接著會關閉應用程式。 當應用程式下次啟動時，就會要求 https://graph.microsoft.com/user.read。 Microsoft Entra ID 會傳回具有 https://graph.microsoft.com/user.read 和 https://graph.microsoft.com/files.readwrite 範圍的存取權杖。 針對使用者授與 https://graph.microsoft.com/files.readwrite 範圍的權杖要求不需要同意。 Microsoft 驗證程式庫 (MSAL) 中的權杖快取會根據授與的權限自動處理快取權杖。 在此範例中，當應用程式重新啟動之後，呼叫 MSAL 以取得具有 https://graph.microsoft.com/files.readwrite 範圍的權杖，會傳回從應用程式初始要求中針對 https://graph.microsoft.com/user.read 範圍快取的權杖。 無需再次呼叫 Microsoft Entra ID。

動態的累加式同意在應用程式註冊期間不需要宣告權限。 不過，強烈建議應用程式宣告應用程式在應用程式註冊中可能需要的任何權限，以支援靜態同意。 管理員可以使用 Microsoft Graph PowerShell 或透過 Microsoft Graph API，在 Microsoft Entra 系統管理中心授與管理員同意。

若要為應用程式授與管理員同意，Microsoft Entra 系統管理中心透過要求同意應用程式的 .default 範圍來使用靜態同意。 如果開發人員未在應用程式註冊中宣告需要權限的應用程式，管理員就無法在 Microsoft Entra 系統管理中心，為其授與管理員同意。

Microsoft Entra ID 客戶可以使用條件式存取原則來保護資源 (API) 和瀏覽器型應用程式。 根據預設，管理員無法套用條件式存取原則至原生應用程式驗證。 租用戶系統管理員可以以 [所有資源] 為目標（先前稱為「所有雲端應用程式」）， 或使用 自定義安全性屬性 ，使用條件式存取原則將原生應用程式設為目標。 即使有其他目標，原則強制執行也不會包含某些存取 Microsoft Graph 或 Azure AD Graph 的應用程式。

除非適用下列案例，否則應用程式通常不需要針對條件式存取使用特殊程式碼。

  • 執行代理者流程的應用程式
  • 存取多個服務或資源的應用程式
  • 使用 MSAL.js 的單頁應用程式
  • 呼叫資源的 Web 應用程式

如果您的應用程式實作上述任一案例，請檢閱適用於 Microsoft Entra 條件式存取的開發人員指引。

免費的 Microsoft Entra ID 租用戶無法利用條件式存取 (請參閱授權需求)。 貴公司的生產租用戶可能具有必要授權。 使用生產租用戶進行測試之前，請先評估這些條件。 有指引可用來建立測試租用戶。

根據預設，條件式存取原則會套用至應用程式及應用程式可在應用程式層級存取的資源。 IT 管理員可以將應用程式層級的原則套用至任何應用程式，而不需開發人員參與。 某些應用程式和案例需要更多細微性。 例如，財務應用程式可能需要多重要素驗證，才能正常使用。 不過，超過指定金額的交易可能需要受控裝置。 開發人員可以透過實作條件式存取驗證內容，讓 IT 管理員將升級條件式存取原則指派給應用程式的不同區域。 條件式存取驗證內容的開發人員指南是了解這些功能的良好參考。

根據預設，Microsoft Entra ID 會發出對設定時間有效的存取權杖。 應用程式絕對不能假設存留期長度。 其必須使用 Microsoft Entra ID 傳回的 expires_in 參數搭配存取權杖。 MSAL 會自動處理此案例。 在存取權杖的存留期內，使用者具有授權，可在授權期間符合條件的情況下存取資源。

條件變更時與原則變更強制執行時之間的延遲，可能會讓管理員和使用者感到擔憂。 例如，當使用者遺失裝置時，IT 管理員可以撤銷該使用者的工作階段。 不過，遺失裝置上的應用程式可以繼續存取該使用者的 Microsoft Graph，直到權杖到期為止。 Microsoft 持續性存取評估 (CAE) 可防止在針對採用 CAE 的應用程式撤銷使用者工作階段之後進行存取。 如果您的應用程式至少一小時會呼叫 Microsoft Graph 一次，則您可以採用 CAE。 如何在您的應用程式中使用已啟用持續性存取評估的 API 會提供實作詳細資料。

如果您無法建置於 MSAL 之上，您的應用程式就必須使用 OAuth 2.0，向 Microsoft Entra ID 要求存取權杖。 Microsoft 身分識別平台和 OAuth 2.0 授權碼流程會提供 Microsoft Entra ID 支援的流程實作詳細資料。

如果您要建置行動裝置應用程式，請檢閱在行動應用程式中支援 SSO 與應用程式防護原則。 了解如何支援權杖取得、Intune 行動應用程式管理 (MAM) 和應用程式防護原則。

資源 (API) 中的授權

應用程式中的授權一節介紹了當應用程式需要存取使用者資源時所需的三個必要授權，但只涵蓋前兩個。 使用者必須具有授權才能存取資源，但 Microsoft Entra ID 不會執行最終授權。 資源 (API) 會執行授權。

API 在為使用者採取行動時，必須強制執行兩個授權：

  • API 必須授權應用程式呼叫 API。 檢查存取權杖的 scp (範圍) 宣告是否包含必要範圍。
  • API 必須授權使用者存取特定資源。 權杖中的 oid (物件識別碼) 和 sub (主體) 宣告代表使用者身分識別。

建議您使用 oid 和 sub 宣告進行授權。

Microsoft Entra ID 會實作成對的 sub 宣告，因此 sub 宣告是唯一適用於要求應用程式的使用者識別碼。 使用不同應用程式的相同使用者會有不同的 sub 宣告。 對於使用者來說，針對所有應用程式的 oid 宣告都是固定的。

應用程式會將必要存取權杖提供給 Microsoft Entra ID，在 http 要求授權標頭中作為持有人權杖來保護的 API。 API 必須完整驗證所收到的權杖，因為該權杖並非直接來自 Microsoft Entra ID。 權杖驗證之前，將呼叫應用程式視為不受信任。 存取權杖參考和宣告驗證參考文章均提供有關驗證 Microsoft Entra ID 存取權杖的詳細資料。

Microsoft Entra ID 會發佈公開金鑰，讓 API 用來驗證權杖的簽章。 這些金鑰會定期變換，以及每當發生需要變換公開金鑰時變換。 您的應用程式絕對不能假設變換公開金鑰的固定排程。 Microsoft 身分識別平台中的簽署金鑰變換會說明如何正確處理公開金鑰變換。

建議您使用受到良好維護的程式庫來執行權杖驗證。 如果您要在 ASP.NET 或 ASP.NET Core 上建置 Web 應用程式或 API，請使用 Microsoft.Identity.Web 來處理權杖驗證。 受保護的 Web API 操作說明文章會說明如何使用 Microsoft.Identity.Web 來保護 API。

API 有時需要呼叫其他 API。 當應用程式為使用者工作時，API 就會收到包含目前使用者身分識別的委派存取權杖。 務必讓 API 只信任來自 Microsoft Entra ID 的已驗證權杖，以判斷目前使用者的身分識別。 這種方法可防止應用程式遭到入侵，從而防止使用者模擬其他使用者並存取不同使用者的資源。 為了在某個 API 呼叫另一個 API 時提供此相同保護，請使用代理者 OAuth 流程來取得存取權杖，為呼叫 API 的使用者呼叫 API。 建置 Web API 來呼叫 Web API 會為 API 提供步驟，針對目前的應用程式使用者呼叫其他 API。

除了委派存取，API 可能還需要支援應用程式，並在沒有目前使用者的情況下獨立運作。 Microsoft Entra ID 會將這些應用程式稱為工作負載。 為了強制執行工作負載授權，API 不會使用 scp (範圍) 宣告。 API 會改用 roles 宣告來驗證工作負載是否具有必要的同意。 API 負責強制工作負載必須具有授權，才能存取資源。

工作負載中的授權

工作負載是獨立運作且沒有目前使用者的應用程式。 如同應用程式中的授權一節中所討論的委派存取，僅限應用程式存取需要數個授權：

  • 應用程式必須具有授權，才能存取特定資源內的特定作業。
  • 應用程式必須具有授權，才能在符合目前條件的情況下存取資源。
  • 應用程式必須具有授權，才能存取資源。

此流程會從要求具有 .default 範圍 (例如 https://graph.microsoft.com/.default) 之存取權杖的工作負載開始。 不同於委派存取 (應用程式可以動態的累加方式要求範圍)，工作負載必須一律使用靜態同意和 .default 範圍。

API 設計師會將角色新增至 API 的應用程式註冊，藉以為其 API 建立應用程式權限。 這些角色具有允許的「應用程式」成員類型，可將角色指派給工作負載。 在 Microsoft Entra 系統管理中心或透過 Microsoft Graph ，將角色指派給工作負載。 在 Microsoft Entra 系統管理中心，必須先取得指派角色的管理員同意，工作負載才能執行。

根據預設，應用程式權限會授權工作負載來存取資源的所有執行個體。 例如，https://graph.microsoft.com/user.read.all 會授權工作負載來存取租用戶中每位使用者的完整使用者設定檔。 IT 管理員通常不願意授與這些廣泛的權限。

對於存取 Microsoft Graph 的工作負載，使用下列方法來限制應用程式權限：

不同於具有使用者的應用程式，工作負載會向 Microsoft Entra ID 進行自我驗證。

針對在 Microsoft Azure 中執行的工作負載，工作負載自我驗證的最佳方法是 Azure 資源受控識別。 受控識別功能不需要管理工作負載認證。 沒有可存取的認證。 認證均由 Microsoft Entra ID 完全管理。 由於不需管理任何認證，因此，所有認證都不會面臨遭到洩漏的風險。

隨著安全性提升，受控識別也會提高復原能力。 受控識別會使用來自 Microsoft Entra ID 的長期存取權杖和資訊，在權杖到期之前取得新權杖。 受控識別會使用區域端點，藉由合併服務相依性來協助防止區域外失敗。 區域端點可協助保留地理區域中的流量。 例如，如果您的 Azure 資源位於 WestUS2，則所有流量都會保留在 WestUS2 中。

如果工作負載未在 Microsoft Azure 中執行，該工作負載就必須透過 OAuth 2.0 用戶端認證流程進行自我驗證。

Microsoft Entra ID 支援下列用戶端認證類型：

  • 憑證。 工作負載會藉由使用私密金鑰簽署判斷提示來證明其擁有該私密金鑰。 私密金鑰不會傳輸至 Microsoft Entra ID。 僅傳送判斷提示。 建議您使用憑證 (而非用戶端密碼)，因為它們更安全且通常可更妥善地管理。
  • 同盟認證。 工作負載識別身分同盟可讓未在 Microsoft Azure 上執行的工作負載使用來自另一個識別提供者、GitHub Actions 或 Kubernetes 叢集的身分識別。 工作負載要求權杖的方式與同盟認證和憑證認證相同。 差異在於判斷提示 (已簽署的 JSON Web 權杖) 來自同盟識別提供者。
  • 用戶端密碼。 用戶端密碼 (有時稱為「應用程式密碼」) 是一個字串值，可讓工作負載用來識別自己。 該密碼的文字值會透過權杖的 POST 要求，從工作負載傳送至 Microsoft Entra ID。 比起憑證或工作負載識別身分同盟，用戶端密碼較不安全。 如果您的工作負載使用密碼，請遵循下列最佳做法來管理密碼。

除了 Microsoft Entra ID 之外，Microsoft Entra 產品系列還包含 Microsoft Entra 工作負載 ID。 Microsoft Entra 工作負載 ID 具有下列進階功能，可增強工作負載安全性。

如果工作負載每小時至少會呼叫 Microsoft Graph 一次，則可支援持續性存取評估 (CAE)。 若要支援 CAE，工作負載必須是單一租用戶應用程式，以及已在其存取 Microsoft Graph 的租用戶中註冊的應用程式。 如果您的工作負載符合這些需求，請參閱此範例 (英文) 以了解實作步驟。

下一步