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

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

概觀

您的應用程式可以取得令牌，代表自己呼叫Web API（而非代表使用者）。 此案例適用於精靈應用程式。 它會使用標準 OAuth 2.0 用戶端認證 授與。

精靈應用程式的一些使用案例範例包括：

• 用來布建或管理用戶或執行目錄中批處理的 Web 應用程式
• 傳統型應用程式（例如 Windows 上的 Windows 服務或 Linux 上的精靈進程）會執行批次作業，或是在背景中執行的作業系統服務
• 需要操作目錄而非特定使用者的 Web API

有另一個常見的情況是，即使非精靈應用程式代表用戶採取行動，也會使用客戶端認證。 基於技術原因，他們需要存取 Web API 或自己的身分識別下的資源時，就會發生這種情況。 例如，針對快取存取 Azure 金鑰保存庫 或 Azure SQL 資料庫 中的秘密。

您無法將精靈應用程式部署到一般用戶的裝置，而一般使用者無法存取精靈應用程式。 只有一組有限的IT系統管理員可以存取執行精靈應用程式的裝置。 如此一來，不良動作專案就無法從裝置流量存取客戶端密碼或令牌，並代表精靈應用程式採取行動。 精靈應用程式案例不會取代裝置驗證。

非精靈應用程式的範例：

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

取得自己身分識別之權杖的應用程式：

• 機密用戶端應用程式必須證明其身分識別，因為它們可以獨立存取用戶的資源。 Microsoft Entra 租用戶系統管理員必須授與這些相當敏感的應用程式核准。
• 已向 Microsoft Entra ID 註冊秘密（應用程式密碼或憑證）。 此秘密會在呼叫 Microsoft Entra ID 以取得令牌期間傳入。

細節

用戶無法與精靈應用程式互動，因為它需要自己的身分識別。 這種類型的應用程式會使用其應用程式身分識別，並將其應用程式標識碼、認證（密碼或憑證）和應用程式標識碼 URI 呈現給 Microsoft Entra ID，以要求存取令牌。 成功驗證之後，精靈會從 Microsoft 身分識別平台 接收存取令牌（以及重新整理令牌）。 接著會使用此令牌來呼叫 Web API（並視需要重新整理）。

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

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

• 精靈應用程式只能在 Microsoft Entra 租用戶中運作。 建置嘗試操作 Microsoft 個人帳戶的精靈應用程式並無意義。 如果您是企業營運 （LOB） 應用程式開發人員，您會在租使用者中建立精靈應用程式。 如果您是ISV，您可能想要建立多租使用者精靈應用程式。 每個租用戶系統管理員都必須提供同意。
• 在應用程式註冊期間，不需要回復 URI。 使用 Microsoft Entra 識別碼共用秘密或憑證或已簽署的判斷提示。 您也需要要求應用程式許可權，並授與系統管理員同意以使用這些應用程式許可權。
• 應用程式 組態 必須在應用程式註冊期間，提供與 Microsoft Entra 識別碼共用的客戶端認證。
• 用來取得具有客戶端認證流程之令牌的範圍必須是靜態範圍。

建議的閱讀資料

如果您不熟悉 OAuth 2.0 和 OpenID 連線 的身分識別和存取管理 （IAM），或甚至剛不熟悉 Microsoft 身分識別平台 上的 IAM，則閱讀清單上應該會高一組下列文章。

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

下一步

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