共用方式為


案例:呼叫 Web API 的精靈應用程式

此案例將引導您建置會呼叫 Web API 的精靈應用程式。

概觀

您的應用程式可以取得權杖來代表本身呼叫 Web API (而不是代表使用者)。 此案例對於精靈應用程式很有用。 其會使用標準 OAuth 2.0 用戶端認證授與。

精靈應用程式

以下是一些適用於精靈應用程式的使用案例範例;

  • 用來佈建或管理使用者或在目錄中進行批次處理的 Web 應用程式
  • 執行批次作業的桌面應用程式 (例如 Windows 上的 Windows 服務或 Linux 上的精靈程序),或在背景執行的作業系統服務
  • 需要操作目錄,而不是特定使用者的 Web API

另一個常見的案例是,即使非精靈應用程式代表使用者採取行動,也會使用用戶端認證。 基於技術原因,他們需要存取 Web API 或在自己的身分識別下的資源時,就會發生這種情況。 範例是存取 Azure Key Vault 中的祕密或存取 Azure SQL Database 的快取。

您無法將精靈應用程式部署至一般使用者的裝置,一般使用者也無法存取精靈應用程式。 只有一群受限的 IT 系統管理員可以存取執行精靈應用程式的裝置。 如此一來,不良執行者就無法從裝置流量存取用戶端密碼或權杖,以及代表精靈應用程式採取行動。 精靈應用程式案例不會取代裝置驗證。

非精靈應用程式範例:

  • 代表應用程式存取 Web 服務,而不是代表使用者的行動應用程式。
  • 代表裝置存取 Web 服務,而不是代表使用者的 IoT 裝置。

針對自己的身分識別取得權杖的應用程式:

  • 保密用戶端應用程式必須證明其身分識別,因為其可以獨立存取使用者的資源。 Microsoft Entra 租用戶系統管理員必須向這些相當敏感的應用程式授與核准。
  • 已向 Microsoft Entra ID 註冊祕密 (應用程式密碼或憑證)。 此祕密會在呼叫 Microsoft Entra ID 以取得權杖期間傳遞。

特性

使用者無法與精靈應用程式互動,因為其需要自己的身分識別。 這類應用程式會使用其應用程式識別,並向 Microsoft Entra ID 出示其應用程式識別碼、認證 (密碼或憑證) 和應用程式識別碼 URI,以要求存取權杖。 成功驗證之後,精靈會從 Microsoft 身分識別平台收到存取權杖 (和重新整理權杖)。 然後,此權杖會用來呼叫 Web API (並視需要重新整理)。

因為使用者無法與精靈應用程式互動,所以不可能進行增量同意。 所有必要的 API 權限都必須在應用程式註冊時進行設定。 應用程式的程式碼只會要求靜態定義的權限。 這也表示精靈應用程式不支援增量同意。

針對開發人員,此案例的端對端體驗具有下列層面:

  • 精靈應用程式只能在 Microsoft Entra 租用戶中運作。 建置可嘗試操作 Microsoft 個人帳戶的精靈應用程式並不合理。 如果您是企業營運 (LOB) 應用程式開發人員,您會在您的租用戶中建立您的精靈應用程式。 如果您是 ISV,您可能會想要建立多租用戶精靈應用程式。 每個租用戶系統管理員都必須提供同意。
  • 應用程式註冊期間,不需要回覆 URI。 使用 Microsoft Entra ID 共用祕密或憑證或簽署的判斷提示。 您也必須要求應用程式權限,並授與系統管理員同意才能使用這些應用程式權限。
  • 應用程式設定必須提供應用程式註冊期間與 Microsoft Entra ID 共用的用戶端認證。
  • 使用用戶端認證流程以取得權杖的範圍必須是靜態範圍。

如果您不熟悉使用 OAuth 2.0 和 OpenID Connect 的身分識別和存取管理 (IAM),或只是初次使用 Microsoft 身分識別平台上的 IAM,則您應將下列文章優先加入閱讀清單中。

雖然在完成您的第一個快速入門或教學課程之前不需要閱讀,但這些文章涵蓋平台不可或缺的主題,而且熟悉這些主題將可在您建立更複雜的案例時,協助您順利進行。

Microsoft 身分識別平台

下一步

移至本案例的下一篇文章,應用程式註冊