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

瞭解建立可呼叫 web Api 的背景程式應用程式所需的一切。

概觀

您的應用程式可以取得權杖來代表本身呼叫 web API (而不是代表使用者) 。 此案例適用于 daemon 應用程式。 其會使用標準 OAuth 2.0 用戶端認證授與。

精靈應用程式

以下是一些適用于 daemon 應用程式的使用案例範例:

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

另一個常見的情況是,非背景程式應用程式會使用用戶端認證:即使它們代表使用者執行動作,他們仍需要在其本身的身分識別下存取 web API 或資源,以確保技術的原因。 例如,存取 Azure Key Vault 中的密碼或快取的 Azure SQL Database。

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

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

特性

使用者無法與 daemon 應用程式互動。 Daemon 應用程式需要自己的身分識別。 這種類型的應用程式會使用其應用程式識別來要求存取權杖,並將其應用程式識別碼、認證 (密碼或憑證) ,以及將應用程式識別碼 URI 呈現給 Azure AD。 成功驗證之後,背景程式會收到 (的存取權杖,以及從 Microsoft 身分識別平臺) 的重新整理權杖。 然後,此權杖會用來呼叫 web API (,並視需要重新整理) 。

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

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

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

如果您不熟悉身分識別和存取管理 (IAM) 與 OAuth 2.0 和 OpenID Connect,或甚至剛接觸到 Microsoft 身分識別平臺上的 IAM,則閱讀清單中的下列一組文章應該會很高。

雖然在完成您的第一個快速入門或教學課程之前不需要閱讀,但它們涵蓋了平臺不可或缺的主題,並熟悉這些主題將可在您建立更複雜的案例時,協助您在路徑上。

Microsoft 身分識別平台

下一步

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