了解僅限應用程式存取
應用程式直接存取資源時，例如 Microsoft Graph，其存取不限於任何單一使用者可用的檔案或作業。 應用程式會使用自己的身分識別直接呼叫 API，而且具有管理員權限的使用者或應用程式必須授權它存取資源。 此案例是僅限應用程式存取。
何時該使用僅限應用程式存取？
在大部分情況下，僅限應用程式存取比委派存取更廣也更強大，因此您應該只在必要時使用僅限應用程式存取。 如果是下列情況，這通常是正確的選擇：
- 應用程式必須以自動化方式執行，不需要使用者輸入。 例如，每日指令碼會檢查來自特定連絡人的電子郵件，並傳送自動化回應。
- 應用程式必須存取屬於多個不同使用者的資源。 例如，備份或資料外洩防護應用程式可能需要從許多不同的聊天頻道擷取訊息，每個頻道都有不同的參與者。
- 您自覺想將認證儲存在本機，並允許應用程式以使用者或管理員「身分」登入。
相反地，使用者通常會登入以自行管理資源時，您不該使用僅限應用程式存取。 這些類型的案例必須使用委派存取，才能獲得最低特殊權限。
授權應用程式進行僅限應用程式呼叫
若要進行僅限應用程式呼叫，您必須為用戶端應用程式指派適當的應用程式角色。 應用程式角色也稱為僅限應用程式權限。 它們是應用程式角色，因為它們只會在定義角色的資源應用程式內容中授與存取。
例如，若要讀取組織建立的所有小組清單，您必須將應用程式指派給 Microsoft Graph Team.ReadBasic.All 應用程式角色。 Microsoft Graph 是資源應用程式時，此應用程式角色會授與讀取此資料的能力。 此指派不會將用戶端應用程式指派給可能允許它透過其他服務檢視此資料的 Teams 角色。
身為開發人員，您必須設定所有必要的僅限應用程式權限，在應用程式註冊也稱為應用程式角色。 您可以透過 Azure 入口網站或 Microsoft Graph 設定應用程式要求的僅限應用程式權限。 僅限應用程式存取不支援動態同意，因此您無法在執行階段要求個別權限或權限集合。
設定應用程式所需的所有權限之後，它必須取得管理員同意，才能存取資源。 例如，只有至少具有特殊權限角色管理員角色的使用者，才能為 Microsoft Graph API 授與僅限應用程式的權限 (應用程式角色)。 像是應用程式系統管理員和雲端應用程式管理員等，具有其他管理員角色的使用者能夠為其他資源授與僅限應用程式的權限。
管理員使用者使用 Azure 入口網站或透過 Microsoft Graph API 以程式設計方式建立授與，即可授與僅限應用程式的權限。 您也可以從應用程式內提示進行互動式同意，但此選項不甚理想，因為僅限應用程式存取不需要使用者。
具有 Microsoft 帳戶的家庭用戶使用者，例如 Outlook.com 或 Xbox Live 帳戶，絕對無法授權僅限應用程式存取。
一律遵循最低權限的準則：您絕對不應要求應用程式不需要的應用程式角色。 如果您的應用程式遭到入侵，此準則有助於限制安全性風險，並讓管理員更容易授與您的應用程式存取權。 例如，如果您的僅限應用程式需要在不讀取詳細個人資料資訊的情況下識別使用者，您應該要求限制較多的 Microsoft Graph User.ReadBasic.All 應用程式角色，而不是 User.Read.All。
設計並發佈資源服務的應用程式角色
如果您要在公開 API 供其他用戶端呼叫的 Microsoft Entra ID 建置服務，不妨支援使用應用程式角色的自動化存取 (僅限應用程式權限)。 您可以在 Microsoft Entra 系統管理中心的應用程式註冊應用程式角色區段中，定義應用程式的應用程式角色。 如需如何建立應用程式角色的詳細資訊，請參閱宣告應用程式的角色。
公開應用程式角色供其他人使用時，請將明確的案例說明提供給要指派這些角色的管理員。 應用程式角色範圍通常應越小越好，並支援特定的功能案例，因為僅限應用程式存取不受使用者權限限制。 請避免公開將完整 read 或完整 read/write 授與您服務包含之所有 API 和資源的單一角色。
注意
應用程式角色 (僅限應用程式權限) 也可以設定為支援為使用者和群組指派。 請確定您已針對預定的存取案例正確設定應用程式角色。 如果您打算讓 API 的應用程式角色用於僅限應用程式存取，請在建立應用程式角色時，選取應用程式作為唯一允許的成員類型。
僅限應用程式存取如何運作？
請切記，僅限應用程式存取最重要的是，呼叫端應用程式以獨立方式和自己的身分識別運作。 不需要使用者互動。 如果應用程式已指派給資源的指定應用程式角色，則應用程式可完全不受限制存取該應用程式角色所控管的所有資源和作業。
應用程式指派給一或多個應用程式角色後 (僅限應用程式權限)，就可以使用用戶端認證流程或任何其他支援的驗證流程，從 Microsoft Entra ID 要求僅限應用程式權杖。 指派的角色會新增至應用程式存取權杖的 roles 宣告。
在某些情況下，應用程式識別碼可能會決定是否授與存取權，與委派呼叫的使用者權限相似。 例如，Application.ReadWrite.OwnedBy 應用程式角色會授與應用程式管理應用程式本身擁有之服務主體的能力。
僅限應用程式存取範例 - 透過 Microsoft Graph 自動傳送電子郵件通知
下列範例說明實際的自動化案例。
Alice 希望在 Windows 檔案共用中的部門報告資料夾登錄新文件時，每次都以電子郵件通知小組。 Alice 建立排程工作，執行 PowerShell 指令碼來檢查資料夾並尋找新檔案。 然後，指令碼會使用資源 API Microsoft Graph 保護的信箱傳送電子郵件。
指令碼會在沒有任何使用者互動的情況下執行，因此授權系統只會檢查應用程式授權。 Exchange Online 會檢查起始呼叫的用戶端是否獲得管理員授與應用程式權限 (應用程式角色) Mail.Send。 如果未將 Mail.Send 授與應用程式，Exchange Online 就會無法成功處理要求。
| POST /users/{id}/{userPrincipalName}/sendMail | 用戶端應用程式已獲授與 Mail.Send | 用戶端應用程式未獲授與 Mail.Send |
|---|---|---|
| 指令碼使用 Alice 的信箱傳送電子郵件。 | 200 - 已授與存取權。 管理員允許應用程式以任何使用者身分傳送郵件。 | 403 - 未經授權。 管理員不允許此用戶端傳送電子郵件。 |
| 指令碼建立專用信箱傳送電子郵件。 | 200 - 已授與存取權。 管理員允許應用程式以任何使用者身分傳送郵件。 | 403 - 未經授權。 管理員不允許此用戶端傳送電子郵件。 |
提供的範例是應用程式授權的簡單圖例。 實際執行的 Exchange Online 服務支援許多其他存取案例，例如將應用程式權限限制為特定 Exchange Online 信箱。