應用程式新增至 Microsoft Entra ID 的方式和原因
Microsoft Entra 的應用程式有兩種表示法：
應用程式物件是什麼？來自何處？
您可以透過 應用程式註冊 體驗管理 Microsoft Entra 系統管理中心的 應用程式 物件。 應用程式物件描述應用程式 Microsoft Entra ID，並可視為應用程式的定義，讓服務知道如何根據其設定向應用程式發出權杖。 應用程式物件只存在於其主目錄中，即使其為在其他目錄中支援服務主體的多租用戶應用程式也是如此。 應用程式物件可能包含下列任一項 (但不限於):
- 名稱、標誌與發行者
- 重新導向 URI
- 祕密 (用於驗證應用程式的對稱和/或非對稱金鑰)
- API 相依性 (OAuth)
- 已發佈的 API/資源/範圍 (OAuth)
- 應用程式角色
- 單一登入 (SSO) 中繼資料和設定
- 使用者發佈中繼資料與設定
- Proxy 中繼資料與設定
您可以透過多個路徑建立應用程式物件，包括：
- Microsoft Entra 系統管理中心的應用程式註冊
- 使用 Visual Studio 建立新的應用程式，並將其設定為使用 Microsoft Entra 驗證
- 當系統管理員從應用程式庫新增應用程式時 (這也會建立服務主體)
- 使用 Microsoft Graph API 或 PowerShell 建立新的應用程式
- 許多其他路徑，包括 Azure 中的各種開發人員經驗，以及在跨開發人員中心的 API 總管體驗
服務主體是什麼，以及其來自哪裡？
您可以透過 企業應用程式 體驗，在 Microsoft Entra 系統管理中心管理 服務 主體。 服務主體是控管連線到 Microsoft Entra ID 的應用程式，而且可以視為您目錄中應用程式的實例。 任何給定的應用程式最多可以有一個應用程式物件 (註冊於「主」目錄)，以及一或多個服務主體物件 (代表應用程式作用所在每個目錄中應用程式的執行個體)。
服務主體可能包括：
- 透過應用程式識別碼屬性對應用程式物件的反向參考
- 本機使用者和群組應用程式角色指派的記錄
- 針對已授與應用程式的本機使用者和系統管理員權限所做的記錄
- 例如：應用程式用來存取特定使用者電子郵件的權限
- 本機原則的記錄，包括條件式存取原則
- 應用程式替代本機設定的記錄
- 宣告轉換規則
- 屬性對應 (使用者佈建)
- 目錄專屬的應用程式角色 (如果應用程式支援自訂角色)
- 目錄專屬的名稱或標誌
和應用程式物件一樣，您也可以透過多個路徑來建立服務主體，包括：
- 當使用者登入與 Microsoft Entra ID 整合的第三方應用程式時
- 登入期間，會要求使用者將權限提供給應用程式，以存取該使用者的設定檔與其他權限。 第一個提供同意的人會產生服務主體，代表已將應用程式新增至目錄。
- 當使用者使用或登入 Microsoft 線上服務，例如 Microsoft 365、Microsoft Entra ID 或 Microsoft Azure。
- 當您第一次使用Microsoft服務時，可能會在目錄中建立一或多個服務主體，代表用來提供服務的各種Microsoft服務識別。 此「Just-In-Time」布建隨時都可能發生，通常是背景程式的一部分。 在極少數情況下，建立的Microsoft服務主體也可能獲指派目錄角色，例如「目錄讀取者」。
- 某些 Microsoft 服務，例如 SharePoint Online 會持續建立服務主體，以允許元件之間的安全通訊，包括工作流程。
- 當系統管理員從應用程式庫新增應用程式時 (這也會建立基礎應用程式物件)
- 新增應用程式以使用 Microsoft Entra 應用程式 Proxy
- 使用 SAML 或密碼 SSO 將應用程式連接到 SSO
- 透過 Microsoft Graph API 或 PowerShell，以程式設計方式建立
應用程式物件與服務主體如何相互關聯？
應用程式在其主目錄中有一個應用程式物件，可供其運作所在每個目錄 (包括應用程式的主目錄) 中的一或多個服務主體來參考。
在前一張圖表中，Microsoft 內部維持用於發佈應用程式的兩個目錄 (顯示於左側)：
- 一個用於 Microsoft 應用程式 (Microsoft 服務目錄)
- 一個用於預先整合的第三方應用程式 (應用程式庫目錄)
與 Microsoft Entra ID 整合的應用程式發行者/廠商必須有發佈目錄 (如「某些軟體即服務 (SaaS) 目錄」所示)。
您自行新增的應用程式 (以圖中的應用程式 (您的) 來代表) 包括：
- 您開發的應用程式 (與 Microsoft Entra ID 整合)
- 為了 SSO 而連線的應用程式
- 您使用 Microsoft Entra 應用程式 Proxy 發佈的應用程式
附註及例外狀況
- 不是所有服務主體都能指回某個應用程式物件。 當 Microsoft Entra ID 最初建置時，提供給應用程式的服務會比較有限，而且服務主體就足以建立應用程式身分識別。 原始服務主體的圖形接近 Windows Server Active Directory 服務帳戶。 基於這個理由，您仍然可以透過不同的路徑建立服務主體，例如使用 Microsoft Graph PowerShell，而不需要先建立應用程式物件。 Microsoft Graph API 需要應用程式物件才能建立服務主體。
- 不是上述所有資訊目前都以程式設計方式公開。 以下功能僅適用於 UI：
- 宣告轉換規則
- 屬性對應 (使用者佈建)
- 如需服務主體和應用程式物件的詳細資訊，請參閱 Microsoft 圖形 API 參考文件：
為什麼應用程式會與 Microsoft Entra ID 整合？
應用程式會新增至 Microsoft Entra ID，以使用其提供的一或多個服務，包括：
- 應用程式驗證和授權
- 使用者驗證和授權
- 使用同盟或密碼的 SSO
- 使用者佈建與同步處理
- 角色型存取控制 (RBAC) - 使用目錄來定義應用程式角色，才能在應用程式中執行角色型授權檢查
- OAuth 授權服務 - Microsoft 365 與其他 Microsoft 應用程式用於授權 API/資源的存取權
- 應用程式發佈與 Proxy - 將應用程式從私人網路發佈到網際網路
- 目錄結構描述延伸模組屬性 - 擴充服務主體和使用者物件的結構描述，以便將其他資料儲存在 entra ID Microsoft
誰有權限可將應用程式新增至我的 Microsoft Entra 執行個體？
根據預設，目錄中的所有使用者都有權註冊他們正在開發的應用程式物件，並決定他們透過同意共用/授與組織數據的存取權。 如果某人是您目錄中第一位登入應用程式並授與同意的使用者，便會在您的租用戶中建立服務主體。 否則，同意授與資訊會儲存於現有服務主體上。
剛聽到要允許使用者註冊並同意應用程式可能會讓您有些疑慮，但請記住下列原因：
- 在無需在目錄中註冊或記錄應用程式的情況下，應用程式能夠使用 Windows Server Active Directory 進行使用者驗證已有數年的時間。 現在組織將改善可見度，以確實了解有多少應用程式正在使用目錄，以及其用途。
- 委派這些責任給使用者會取消管理員驅動之應用程式註冊與發佈處理序的需求。 有了 Active Directory Federation Services (ADFS)，系統管理員很有可能必須代表其開發人員，將應用程式新增為信賴憑證者。 現在開發人員可以自助。
- 使用者使用其組織帳戶登入應用程式對於商務程序來說是件好事。 若使用者之後離開組織，他們就會自動失去其在先前所用應用程式中帳戶的存取權。
- 擁有與哪些應用程式共用什麼資料的記錄是件好事。 資料比以往更容易傳送，擁有誰與哪些應用程式共用什麼資料的清楚記錄很實用。
- 針對 OAuth 使用 Microsoft Entra ID 的 API 擁有者會確實決定使用者能夠授與應用程式什麼權限，以及哪些權限需要管理員同意。 只有管理員可以同意更大範圍且較重要的權限，而使用者同意則限定在使用者自身資料與功能的範圍內。
- 當使用者新增或允許應用程式存取其資料時，可以稽核事件，以便您可以在 Microsoft Entra 系統管理中心內檢視稽核報告，以判斷如何將應用程式新增至目錄。
如果您仍想讓目錄中的使用者在未獲得系統管理員核准時，就無法註冊應用程式和登入應用程式，您可以變更兩項設定以關閉這些功能：
若要變更您組織中的使用者同意設定，請參閱設定使用者同意應用程式的方式。
若要防止使用者註冊自己的應用程式：
- 在 Microsoft Entra 系統管理中心，瀏覽至 [身分識別]>[使用者]>[使用者設定]。
- 將 [使用者可以註冊應用程式] 變更為 [否]。