共用方式為


在 Microsoft Entra ID 生態系統中建立應用程式

在 Microsoft Entra ID 上建置應用程式時,您必須先建立應用程式的身分識別。 應用程式需要 Microsoft Entra ID 中的身分識別來要求權杖。 應用程式開發介面 (API) 需要 Microsoft Entra ID 中的身分識別,才能發放讓應用程式存取資源的權杖。

在本文中,您將了解如何在 Microsoft Entra 系統管理中心的 Microsoft Entra ID 租用戶中註冊應用程式,或使用 Microsoft Graph API。 這是一系列文章中的第二篇,說明獨立軟體開發人員 (ISV) 如何建置適用於 Microsoft Entra ID 的應用程式並將其最佳化。 在此系列中,您可以深入了解下列主題:

  • 適用於獨立軟體開發人員的 Microsoft Entra ID 描述如何使用此雲端式身分識別和存取權管理服務,讓員工能夠使用您的應用程式存取資源。
  • 驗證應用程式和使用者描述應用程式如何使用 Microsoft Entra ID 來驗證使用者與應用程式。
  • 授權應用程式、資源和工作負載描述個人何時會與應用程式互動並引導應用程式、API 何時會為使用者採取行動,以及應用程式或服務何時會獨立運作。
  • 自訂權杖可協助您使用來自 Microsoft Entra ID 的識別碼權杖和存取權杖,在應用程式中建置安全性。 其描述您可在 Microsoft Entra ID 權杖中接收到的資訊,以及如何自訂它們。

註冊應用程式

開發人員可以將應用程式註冊為多租用戶應用程式和單一租用戶應用程式。 建議您針對 ISV 使用多租用戶應用程式。 多租用戶應用程式具有 ISV 在其租用戶中完全控制及註冊的單一應用程式註冊。 了解如何建立Microsoft Entra ID 租用戶來註冊您的應用程式。

若要為任何執行 Microsoft Entra ID 的客戶提供解決方案,並在其登入客戶 Microsoft Entra ID 租用戶時提供順暢的體驗,請依序前往 [Microsoft Entra 系統管理中心]、[應用程式註冊]、[註冊應用程式]。 請在這個新的應用程式註冊中依序選取 [支援的帳戶類型]、[任何組織目錄中的帳戶 (任意 Microsoft Entra ID 租用戶--多租用戶)] 或 [任何組織目錄中的帳戶 (任意 Microsoft Entra ID 租用戶--多租用戶) 及個人的 Microsoft 帳戶 (例如: Skype、Xbox)]

Microsoft Entra 系統管理中心內的應用程式組態選項螢幕擷取畫面。

將多租用戶應用程式上線至外部租用戶的流程,也可以像執行應用程式並讓使用者登入應用程式一樣簡單。 當租用戶允許使用者同意時 (使用者可以登入應用程式,而不需要系統管理員事前核准應用程式),使用者只需要登入應用程式即可上線應用程式。 這段開發人員身分識別研討會影片 (時間碼 1:05:20 至 1:08:00) 展示了應用程式會在使用者登入應用程式時上線至租用戶。

當您在 Microsoft Entra ID 租用戶中註冊應用程式時,該租用戶會收到應用程式識別碼 (App ID),也稱為應用程式的用戶端識別碼。 因為該識別碼可唯一識別應用程式,所以這就像是使用者的 userid。 應用程式識別碼在 Microsoft Entra ID 雲端內具有全域唯一性,而且不可變。 應用程式與 Microsoft Entra 識別碼之間的所有互動都會涉及應用程式識別碼。

除了應用程式識別碼之外,應用程式註冊還包含應用程式開發人員知道或需要知道的應用程式相關資訊。 例如,應用程式開發人員必須知道應用程式識別碼,才能與 Microsoft Entra ID 互動。 開發人員知道他們正在建置的應用程式類型 (Web 應用程式、原生應用程式、單一頁面應用程式、行動應用程式或傳統型應用程式)。 應用程式類型具有必要的屬性。

例如,其中一項必要的應用程式屬性是重新導向統一資源識別項 (URI)。 該屬性會向 Microsoft Entra ID 告知驗證或授權之後傳送給使用者的網站位址或原生應用程式位址。 開發人員會根據應用程式類型和應用程式執行位置,了解應用程式的重新導向 URI。

應用程式的資訊清單 (您可以從 Microsoft Entra 系統管理中心存取,或使用 Microsoft Graph API 存取) 會儲存許多應用程式屬性。 請參考了解 Microsoft Entra 應用程式資訊清單,以了解應用程式屬性及其允許的值。

請參考Microsoft 身分識別平台驗證和授權的程式碼範例,以探索您要開發之應用程式的建議設定。 尋找類似於您要建置之應用程式的應用程式範例,並閱讀其文件。 範例會依應用程式類型詳細說明所需的應用程式註冊設定。 例如,如果您在 Node.js 內建置 API,您可以找到引導您前往這些註冊指示的範例。

應用程式註冊會傳達開發人員所具備的知識。 在使用者可以向多租用戶應用程式進行驗證的每個租用戶中,租用戶管理員會設定應用程式在其租用戶內的執行方式。 例如,租用戶管理員可以設定條件式存取原則,將應用程式限制在特定網路位置。 此外,可能會有條件式存取原則要求使用者經過多重要素驗證 (MFA) 才能存取應用程式,或具有允許特定使用者或群組使用應用程式的應用程式設定。

若要啟用這類限制,租用戶管理員會需要其租用戶內的應用程式控制點。 Microsoft Entra ID 會自動在使用者驗證應用程式的每個租用戶中建立企業應用程式。 在 Microsoft Entra 系統管理中心,這些應用程式稱為企業應用程式,但該物件為服務主體。 深入了解 Microsoft Entra ID 中的應用程式和服務主體

在使用者驗證應用程式之後,Microsoft Entra ID 會在使用者驗證的租用戶中建立服務主體。 租用戶管理員可以使用 Microsoft Graph 中的服務主體物件 (或在 Microsoft Entra 系統管理中心企業應用程式內) 設定應用程式在租用戶中的執行方式。

儘管服務主體和應用程式註冊有許多相同的屬性,但服務主體並非應用程式註冊的副本。 相反地,服務主體會連結至其應用程式註冊。 您可以在連結的企業應用程式中檢視應用程式註冊的更新。 客戶無法針對多租用戶應用程式來存取留在 ISV 租用戶內的應用程式註冊。 不過,即使應用程式的服務主體位於不同的租用戶中,應用程式也可以使用 Microsoft Graph 存取其服務主體。 因此,應用程式可以存取企業應用程式的相關屬性 (例如,其是否需要將使用者指派給應用程式,或在應用程式中將角色指派給使用者)。

雖然我們建議 ISV 使用多租用戶應用程式來進行應用程式註冊,但單一租用戶應用程式也是註冊應用程式時的另一個可用選項。 除了在 ISV 租用戶 (ISV 可完全控制註冊) 中註冊單一應用程式外,您也可以請求客戶在其租用戶中註冊您的應用程式。 在客戶完成註冊之後,客戶會使用其應用程式註冊的詳細資料來設定您的應用程式執行個體。 建議您將這項單一租用戶應用程式方法專門用在為特定企業開發的企業營運應用程式。

因為客戶會在註冊和設定應用程式時造成額外負荷,所以不建議您針對 ISV 使用單一租用戶應用程式。 不過在部分案例中,您無法選擇多租用戶應用程式來作為您的應用程式。

如果您的應用程式使用安全性聲明標記語言 2.0 (SAML),而不是 OpenID Connect (OIDC) 或 OAuth 2.0,則應用程式會遵循單一租用戶應用程式註冊模型。 針對 SAML 應用程式,建立服務主體和應用程式註冊的順序與 OIDC 或 OAuth 2.0 應用程式相反 (至少對於將 SAML 應用程式新增至租用戶的系統管理員而言,順序是相反的)。 系統管理員並不會註冊應用程式,並讓 Microsoft Entra ID 自動建立服務主體,而是會從建立企業應用程式著手。 Microsoft Entra ID 會自動建立應用程式註冊。 Microsoft Entra ID 應用程式資源庫 (如 發佈應用程式 一節所述) 可簡化系統管理員的 SAML 應用程式建立流程。

重新導向統一資源識別碼 (URI) 的限制可以防止 ISV 建立多租用戶應用程式。 應用程式最多可以擁有 256 個重新導向 URI (不含萬用字元)。 如果您的應用程式需要每位客戶的唯一重新導向 URI,而且需要唯一執行個體的客戶超過 256 位,您可能無法建立多租用戶應用程式。 基於安全性考慮,您無法在 Microsoft Entra ID 重新導向 URI 中使用萬用字元 (*)。 您可採取的其中一個選項,是為您的中央服務 (如果可用的話) 提供單一重新導向 URI。 中央重新導向 URI 會驗證權杖,然後將使用者重新導向至其客戶特定端點。

發佈應用程式

當使用者開始驗證您的應用程式,或授權應用程式存取使用者的資源時,使用者會決定其是否信任您的應用程式。 系統管理員可以代表租用戶中的所有使用者做出類似的決策。 系統管理員可以決定使用者是否登入應用程式,以及應用程式是否存取特定資源。

下列應用程式發行方法可協助 ISV 將其應用程式呈現為值得使用者和系統管理員信任的應用程式。

  • 已驗證的網域發佈您的應用程式。 發行者網域會項使用和系統管理員通知其資訊的發送目的地位置。 從已驗證的發行者網域進行發佈,即表明應用程式的已註冊租用戶可控制列為應用程式發行者的網域。
  • 使用發行者驗證來發佈您的應用程式。 擁有已驗證的發行者網域,不僅可表明應用程式發行者擁有網域的控制權,而且還是使用發行者驗證的必要條件。 發行者驗證可顯示 Microsoft 驗證了網域和租用戶背後的實體為真實可信。 非系統管理員的使用者通常不會信任來自未驗證發行者的多租用戶應用程式。 系統管理員可以對租用戶進行設定,讓來自非驗證發行者的應用程式一律需要系統管理員同意。 發行者驗證主要是針對在 OAuth 2.0 和 OIDC 上建置多租用戶應用程式的 ISV。 已驗證的發行者會是 Microsoft Cloud Partner Program 的成員。 發行者驗證不會影響單一租用戶應用程式,例如使用 SAML 或企業營運應用程式的應用程式。
  • Microsoft Entra ID 應用程式資源庫中發佈您的應用程式。 您可以在 Microsoft Entra ID 應用程式資源庫中,要求Microsoft 列出使用 SAML 2.0、OAuth 2.0 和 OIDC 的應用程式。 系統管理員會透過 [Microsoft Entra 系統管理中心]、[企業應用程式]、[新的應用程式],在 Microsoft Entra ID 應用程式資源庫中尋找預先整合的應用程式。 在 Microsoft Entra ID 應用程式資源庫中發佈您的應用程式,可簡化應用程式設定,並將所需設定的項目降至最低。 Microsoft 會測試應用程式並提供相容性驗證,這對於採用 SAML 2.0 並在使用之前需要設定的應用程式而言特別有用。 您可以使用應用程式的跨網域身分識別管理系統 (SCIM) 2.0 實作,以設定應用程式資源庫應用程式進行佈建的方式。詳細資訊請參閱自動佈建一節。 若要開始使用,請提交要求來發佈您的應用程式。 您可以使用 SCIM 來搭配應用程式資源庫中的單一應用程式,以實現單一登錄和使用者佈建。
  • 參與 Microsoft 365 應用程式合規性計劃 使用已驗證的網域即代表您具有網域的控制權。 發行者驗證會顯示 Microsoft 驗證了您的組織為真實可信。 在 Microsoft Entra ID 應用程式資源庫中列出您的應用程式,即表示您的應用程式可與 Microsoft Entra ID 搭配運作,並能夠輕鬆上線。 Microsoft 365 合規性計劃可讓您透過發行者證明Microsoft 365 認證,或使用 Azure 中的應用程式合規性自動化工具 (ACAT),向客戶通知應用程式的安全性與合規性。 這會顯示您的應用程式如何保護客戶授權應用程式存取的資源。

自動佈建

Microsoft Entra ID 中的應用程式佈建可以自動將使用者身分識別、群組物件和角色佈建至使用者需要存取的雲端應用程式。 除了建立使用者和群組物件以外,自動佈建還涉及到隨著狀態或角色變更,而維護和移除使用者身分識別。 Microsoft Entra 佈建服務可藉由呼叫應用程式所提供的 SCIM 物件管理 API 端點,自動將使用者和群組佈建至應用程式。

對於 ISV 而言,在 Microsoft Entra ID 中佈建應用程式的優點如下。

  • 可使用 Microsoft Graph 佈建至您的應用程式,建置 SCIM 端點可讓佈建與支援 SCIM 的識別提供者 (IdP) 搭配運作。 大部分的 IdP 都支援 SCIM 佈建通訊協定。
  • 佈建是一項同步處理作業,其中的資料會在 Microsoft Entra ID 與應用程式之間進行同步處理。 若要實作 Microsoft Graph 型同步處理解決方案,應用程式需要存取租用戶中所有使用者和群組的所有屬性。 部分 Microsoft Entra ID 客戶不願意允許這類大範圍存取。 透過 SCIM,系統管理員可以選取 Microsoft Entra ID 會同步處理至應用程式的屬性。 許多系統管理員更偏好於擁有這種微調控制項 (此控制項僅適用於 SCIM 實作)。
  • 建置您自己的 Microsoft Graph 同步處理服務以進行佈建代表著您必須管理服務,並實作提取模型來監視 Microsoft Entra ID 上的變更。 當您實作 SCIM 端點時,Microsoft Entra ID 會管理佈建服務管理,並將變更推送至您的應用程式。

使用 SCIM、Microsoft Graph 和 Microsoft Entra ID 來佈建使用者,並使用資料擴充應用程式可提供何時使用 SCIM 和 Microsoft Graph 的指引。 您可以使用 Microsoft 文件來透過 Microsoft Entra ID 規劃建置驗證 SCIM 端點,並解決 SCIM 合規性的已知問題

除了將資料同步處理至應用程式之外,Microsoft Entra ID 還提供使用雲端式人力資源 (HR) 應用程式進行佈建的功能。 HR 導向的佈建是根據人力資源解決方案建立數位身分識別的流程。 HR 系統會成為這些新建數位身分識別的起始授權,而且通常是許多佈建流程的起始點。 內部部署 HR 解決方案可以使用 Microsoft Identity Manager,將使用者佈建至內部部署的 Active Directory。 然後,您可以使用 Microsoft Entra Connect 將使用者同步至 Microsoft Entra ID,或直接同步至 Microsoft Entra ID。

透過 API 導向的輸入佈建,雲端式 HR ISV 可以傳遞原生同步處理體驗,讓 HR 系統中的變更自動流入 Microsoft Entra ID 和連結的內部部署 Active Directory 網域。 例如,HR 應用程式或學生資訊系統應用程式可以在交易完成或每日大量更新時,立即將資料傳送至 Microsoft Entra ID。 若要著手了解 API 導向的輸入佈建概念,請研究 Microsoft Graph 中的 bulkUpload 功能,並熟悉 API 導向的佈建概念、案例和限制

下一步