共用方式為


從另一個 API 呼叫 API

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

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

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

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

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

用戶端應用程式會取得存取令牌以呼叫原始 API

下圖顯示用戶端應用程式和原始 API。

圖表顯示具有標識碼和存取令牌的用戶端應用程式,以及需要授權的原始API。

用戶端應用程式取得原始 API 的委派許可權存取令牌(由五角大樓圖形以 “A” 標籤表示)。 委派的許可權存取令牌可讓其代表使用者呼叫需要授權的原始 API。

用戶端應用程式提供原始 API 的存取令牌

下列動畫顯示用戶端應用程式將存取令牌授與原始 API。 原始 API 會完整驗證並檢查存取令牌,以判斷用戶端應用程式使用者的身分識別。

動畫圖表顯示用戶端應用程式授與需要授權的原始 API 存取令牌。

原始 API 會執行令牌驗證和強制執行

下一個動畫顯示,在用戶端應用程式提供原始 API 的存取令牌之後,原始 API 會執行令牌驗證和強制執行。 如果一切順利,API 會繼續並服務用戶端應用程式的要求。

動畫圖表顯示左側具有標識元令牌的用戶端應用程式,將存取令牌授與右邊的原始 API。

原始 API 無法使用存取令牌來呼叫下游 API

下列動畫顯示原始 API 現在想要呼叫下游 API。 不過,原始 API 無法使用存取令牌來呼叫下游 API。

動畫圖表顯示用戶端應用程式將存取令牌授與原始 API。需要授權可防止原始 API 將令牌提供給下游 API。

原始 API 會回到Microsoft Entra 識別碼

在下列動畫中,原始 API 必須回到 entra 識別碼Microsoft。 它需要存取令牌,才能代表使用者呼叫下游 API。

動畫圖表顯示用戶端應用程式將存取令牌授與原始 API,而原始 API 需要從 Microsoft Entra 識別碼進行驗證,以呼叫下游 API。

下一個動畫顯示原始 API,提供來自用戶端應用程式的原始 API 和原始 API 用戶端認證所收到的令牌。

動畫圖表顯示用戶端應用程式將存取令牌授與原始 API,以接收來自Microsoft Entra 標識碼的驗證,以呼叫下游 API。

Microsoft Entra ID 會檢查同意或條件式存取強制執行等專案。 您可能必須返回呼叫用戶端,並提供無法取得令牌的原因。 您通常會使用 宣告挑戰 程式回到呼叫端應用程式,其中包含未收到同意的資訊(例如與條件式存取原則相關)。

Microsoft Entra ID 執行檢查

在下列動畫中,Microsoft Entra ID 會執行其檢查。 如果一切正常,Microsoft Entra ID 會發出原始 API 的存取令牌,以代表使用者呼叫下游 API。

動畫圖表顯示原始 API 在使用 Microsoft Entra 識別碼進行驗證之後,將存取令牌授與下游 API。

原始 API 具有代理者流程的用戶內容

下列動畫說明 允許 API 在呼叫下游 API 時繼續擁有用戶內容的代理者流程 (OBO) 程式。

動畫圖表顯示原始 API 授與下游 API 的存取令牌。

原始 API 呼叫下游 API

在下一個動畫中,我們會呼叫下游 API。 下游 API 收到的令牌具有適當的物件 (aud) 宣告,表示下游 API。

動畫圖顯示從原始 API 驗證存取令牌的下游 API。

令牌包含授與同意的範圍和原始應用程式使用者身分識別。 下游 API 可以正確實作有效的許可權,以確保已識別的使用者具有完成要求工作的許可權。 您想要代表流程使用 來取得 API 的令牌,以呼叫另一個 API,以確保使用者內容會傳遞至所有下游 API。

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

最後一個動畫顯示,最佳選項是讓原始 API 執行代理者流程 (OBO)。 如果下游 API 收到正確的令牌,它可以正確回應。

動畫圖顯示從原始 API 接收存取令牌的下游 API。

當 API 代表使用者採取行動,且需要呼叫另一個 API 時,API 必須使用 OBO 來取得委派的許可權存取令牌,以代表使用者呼叫下游 API。 API 不應該在 API 代表使用者採取行動時,使用應用程式許可權來呼叫下游 API。

下一步