Microsoft 身分識別平台中的權限和同意概觀
若要存取受保護的資源，例如電子郵件或行事歷資料，您的應用程式需要資源擁有者的授權。 該資源擁有者可以同意或拒絕您的應用程式要求。 了解這些基本概念將協助您建置更安全且更值得信任的應用程式 (這些應用程式只會在需要時向使用者和系統管理員要求所需的存取權)。
存取情節
身為應用程式開發人員，您必須確定您的應用程式將如何存取資料。 應用程式可以使用委派的存取權 (代表登入的使用者進行運作) 或僅應用程式存取權 (僅作為應用程式自己的身分識別進行運作)。
委派的存取權 (代表使用者的存取權)
在此存取案例中，使用者已登入用戶端應用程式。 用戶端應用程式會代表使用者存取資源。 委派的存取權需要委派的權限。 用戶端和使用者都必須分別獲得授權才能提出要求。 如需委派存取案例的詳細資訊，請參閱委派存取案例。
對於用戶端應用程式，必須授與正確的委派權限。 委派的權限也可以稱為範圍。 範圍是給定資源的權限，代表用戶端應用程式可以代表使用者存取的內容。 如需範圍的詳細資訊，請參閱範圍和權限。
授權依賴於使用者已被授與其可以存取資源的權限。 例如，使用者可藉由 Microsoft Entra 角色型存取控制 (RBAC) 取得目錄資源存取權限，或藉由更換線上 RBAC 存取電子郵件和行事曆資源。 如需應用程式 RBAC 的詳細資訊，請參閱應用程式的 RBAC。
僅應用程式存取權 (沒有使用者的存取權)
在此存取案例中，應用程式會自行運作，無需使用者登入。 應用程式存取用於自動化和備份等情節中。 此案例包括以背景服務或精靈身分執行的應用程式。 如果不想讓特定使用者登入，或所需資料的範圍無法限定為單一使用者時，它就很合適。 如需僅限應用程式存取案例的詳細資訊，請參閱僅限應用程式存取。
僅應用程式存取權會使用應用程式角色，而不是委派的範圍。 透過同意授與時，應用程式角色也可能稱為應用程式權限。 用戶端應用程式必須被授與其呼叫之資源應用程式的適當應用程式權限。 授與之後，用戶端應用程式即可存取要求的資料。 如需將應用程式角色指派給用戶端應用程式的詳細資訊，請參閱將應用程式角色指派給應用程式。
權限類型
委派權限會用於委派的存取情節中。 這些權限可讓應用程式代表使用者採取行動。 應用程式永遠無法存取登入使用者自己無法存取的任何內容。
例如，取得已代表使用者授與 Files.Read.All 委派權限的應用程式。 該應用程式將只能讀取使用者個人可存取的檔案。
應用程式權限 (也稱為應用程式角色) 使用於僅限應用程式存取案例，而不會有登入的使用者存在。 該應用程式將能夠存取與該權限相關聯的任何資料。
例如，授與 Microsoft Graph API 應用程式權限 Files.Read.All 的應用程式，將能夠使用 Microsoft Graph 讀取租用戶中的任何檔案。 一般而言，只有 API 服務主體的系統管理員或擁有者可同意該 API 所公開的應用程式權限。
委派權限與應用程式權限的比較
| 權限類型 | 委派的權限 | 應用程式權限 |
|---|---|---|
| 應用程式類型 | Web / 行動 / 單頁應用程式 (SPA) | Web/精靈 |
| 存取內容 | 代表使用者進行存取 | 無需使用者即進行存取 |
| 有權同意者 | - 使用者可以同意其資料 - 管理員可以同意所有使用者 |
僅管理員可同意 |
| 同意方法 | - 靜態：應用程式註冊的已設定清單 - 動態：在登入時要求個別權限 |
- 僅限靜態：應用程式註冊的已設定清單 |
| 其他名稱 | - 範圍 - OAuth2 權限範圍 |
- 應用程式角色 - 僅限應用程式權限 |
| 同意結果 (Microsoft Graph 專屬) | OAuth2PermissionGrant | 應用程式角色指派 |
同意
授與應用程式權限的其中一種方式是透過同意。 同意是使用者或系統管理員授權應用程式存取受保護資源的程序。 例如，當使用者第一次嘗試登入應用程式時，該應用程式可以要求查看使用者的設定檔及讀取使用者的信箱內容的權限。 使用者可透過同意提示來查看應用程式要求的權限清單。 使用者可能會看到同意提示的其他情況包括：
- 當先前授與的同意被撤銷時。
- 當應用程式被編碼為在登入期間專門提示同意時。
- 當應用程式使用動態同意在執行階段依所需要求新權限時。
同意提示的主要詳細資料為應用程式所需的權限清單以及發行者資訊。 如需管理員和終端使用者同意提示和同意體驗的詳細資訊，請參閱應用程式同意體驗。
使用者同意
當使用者嘗試登入應用程式時，就會發生使用者同意。 使用者會提供其登入認證，系統會檢查認證以判斷是否已獲得同意。 如果沒有之前的使用者或管理員同意所需權限的記錄，則系統會向使用者顯示一個同意提示，並要求授與應用程式所要求的權限。 管理員可能需要代表使用者授予同意。
系統管理員同意
根據其所需的權限，有些應用程式可能需要系統管理員成為授與同意者。 例如，應用程式權限和許多高權限的委派權限只能由系統管理員同意。
系統管理員可以為自己或整個組織授與同意。 如需使用者和管理員同意的詳細資訊，請參閱使用者和管理員同意概觀。
如果未獲得同意，而且要求其中一個高權限的權限，系統會提示驗證要求以取得系統管理員同意。
包含自訂應用程式範圍的權限要求不會被視為高權限，因此不需要系統管理員同意。
預先授權
預先授權可讓資源應用程式擁有者授與權限，而不需要使用者看到針對已預先授權的同一個權限集的同意提示。 這樣，已預先授權的應用程式就不會要求使用者同意權限。 資源擁有者可以在 Azure 入口網站或使用 PowerShell 和 API (例如 Microsoft Graph) 對用戶端應用程式進行預先授權。
其他授權系統
同意架構只是應用程式或使用者可以授權存取受保護資源的一種方式。 系統管理員應該注意可能會授與敏感性資訊存取權的其他授權系統。 Microsoft各種授權系統的範例包括 Entra 內建角色、Azure RBAC、Exchange RBAC 和 Teams 資源特定同意。