共用方式為


從另一個 API 呼叫 API

身為開發人員,當您有一個需要呼叫另一個 API 的 API 時,如何 確保零信任 ? 在本文中,您會瞭解如何在應用程式代表用戶運作時安全地開發應用程式。

當使用者驅動應用程式的 UI 時,應用程式可能會使用委派的許可權,讓 API 知道代表應用程式運作的使用者。 它會檢查應用程式在呼叫 API 時所提供存取令牌中的主體宣告(sub)、物件識別碼宣告(oid)和租使用者識別碼宣告(tid)。 API 不會依賴不受信任的應用程式,這只是來自網路上某處的請求。 相反地,它會驗證令牌,以確保 API 只能代表Microsoft Entra ID 驗證的應用程式用戶運作。

當某個 API(我們將其稱為 原始 API)呼叫另一個 API 時,我們呼叫的 API 非常重要(我們將其稱為 下游 API)遵循驗證程式。 下游 API 無法依賴不受信任的網路來源。 它必須從正確驗證的存取令牌取得使用者身分識別。

如果下游 API 未遵循適當的驗證程式,下游 API 必須依賴原始 API,以另一種方式提供使用者的身分識別。 下游 API 可能會錯誤地使用應用程式許可權來執行作業。 然後,原始 API 會成為用戶可針對下游 API 達成哪些結果的唯一授權單位。 原始 API 可以刻意(或無意中)允許使用者完成用戶無法完成的工作。 例如,一位使用者可以變更其他使用者的詳細數據,或讀取和更新用戶無權存取的檔。 不正確的驗證可能會導致嚴重的安全性問題。

為了獲得更好的安全性,原始 API 會取得 委派的許可權 存取令牌,以在原始 API 進行呼叫時提供給下游 API。 讓我們逐步解說其運作方式。

  1. 用戶端應用程式會取得存取令牌以呼叫原始 API。 用戶端應用程式會取得原始 API 的委派許可權存取令牌。 委派的許可權存取令牌可讓其代表使用者呼叫需要授權的原始 API。
  2. 用戶端應用程式會提供原始 API 的存取令牌。 用戶端應用程式會提供原始 API 的存取令牌。 原始 API 會完整驗證並檢查存取令牌,以判斷用戶端應用程式使用者的身分識別。
  3. 原始 API 會執行令牌驗證和強制執行。 用戶端應用程式將存取令牌提供給原始 API 之後,原始 API 會執行令牌驗證和強制執行。 如果一切順利,API 會繼續並服務用戶端應用程式的要求。
  4. 原始 API 無法使用存取令牌來呼叫下游 API。 原始 API 想要呼叫下游 API。 不過,原始 API 無法使用存取令牌來呼叫下游 API。
  5. 原始 API 會回到 Microsoft Entra 識別碼。 原始 API 必須回到 Microsoft Entra 識別碼。 它需要存取令牌,才能代表使用者呼叫下游 API。 原始 API 提供從用戶端應用程式接收到的令牌以及原始 API 的用戶端認證。
  6. Microsoft Entra ID 會執行檢查。 Microsoft Entra ID 會檢查同意或條件式存取強制執行等專案。 您可能必須返回呼叫用戶端,並提供無法取得令牌的原因。 您通常會使用 宣告挑戰 流程回到呼叫端應用程式,其中包含有關未收到同意的資訊(例如與條件式存取原則相關)。 如果一切正常,Microsoft Entra ID 會發出原始 API 的存取令牌,以代表使用者呼叫下游 API。
  7. 原始 API 具有 On-Behalf-Of 流程的用戶內容。 On-Behalf-Of flow(OBO)流程可讓 API 在呼叫下游 API 時繼續保有用戶內容。
  8. 原始 API 會呼叫下游 API。 呼叫下游 API。 下游 API 收到的令牌具有適當的物件 (aud) 宣告,表示下游 API。 令牌包含授與同意的範圍和原始應用程式使用者身分識別。 下游 API 可以正確實作有效的許可權,以確保已識別的使用者具有完成要求工作的許可權。 您想要代表流程使用 來取得 API 的令牌,以呼叫另一個 API,以確保使用者內容會傳遞至所有下游 API。

最佳選項:原始 API 會執行代理者流程

最佳選項是讓原始 API 執行 On-Behalf-Of 流程(OBO)。 如果下游 API 收到正確的令牌,它可以正確回應。 當 API 代表使用者採取行動,且需要呼叫另一個 API 時,API 必須使用 OBO 來取得委派的許可權存取令牌,以代表使用者呼叫下游 API。 API 不應該在 API 代表使用者採取行動時,使用應用程式許可權來呼叫下游 API。

下一步