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

了解建置會呼叫 Web API 的精靈應用程式所需項目。

概觀

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

Daemon apps

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

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

另一個常見的情況是非精靈應用程式會使用用戶端認證:基於技術原因。即使其代表使用者執行動作,仍需要在其本身的身分識別下存取 Web API 或資源。 範例是存取 Azure Key Vault 中的祕密或存取 Azure SQL Database 的快取。

注意

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

非精靈應用程式範例:

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

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

  • 是機密用戶端應用程式。 這些應用程式,假設可獨立於使用者來存取資源,需要證明其身分識別。 也是相當敏感性的應用程式。 必須由 Azure Active Directory (Azure AD) 租用戶系統管理員核准。
  • 已向 Azure AD 註冊祕密 (應用程式密碼或憑證)。 此祕密會在呼叫 Azure AD 期間傳入,以取得權杖。

特性

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

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

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

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

若您不熟悉使用 OAuth 2.0 與 OpenID Connect 的身分識別與存取管理 (IAM),或甚至第一次使用 Microsoft 身分識別平台上的 IAM,則應將下列文章集優先加入您的閱讀清單。

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

Microsoft 身分識別平台

後續步驟

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