OAuth2：客戶端憑據流

Question

問題：我目前正在致力於為客戶端提供 REST Api（在這種情況下，客戶端不是訂購文章的普通最終用戶，而是與我的系統通信的客戶端的 Web Api）。 為了在我的系統中訂購不同的產品，每個客戶可能針對每個國家分別擁有多個帳戶。 身份驗證是通過將客戶端的 WebApi 應用程序身份驗證到我的系統（機器對機器）來完成的。 所以看起來這應該使用基於文章https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios#scenarios- 的OAuth2 客戶端憑據流來完成-supported-authentication-flows，但我對每個國家/地區的客戶帳戶問題分別表示懷疑。

問題：這應該通過為每個國家/地區的每個客戶賬戶分別創建一個 ClientId 和 ClientSecret 來解決，或者，應該創建一個客戶賬戶，而國家應該在每次請求 Api 或添加國家之前由客戶發送作為訪問令牌的范圍或聲明。 此外，我不確定在這種情況下 Client Credentials Flow 是否是一個不錯的選擇，因此我將非常感謝您提供任何建議。

Answer 1

客戶

理想情況下，每個客戶公司都應該擁有一個用於獲取訪問令牌的客戶憑證。 在某些情況下，例如當有不同的法律細分時，這可以擴展。 默認情況下使用單個值，但您需要了解您的客戶。

如果需要，公司之間的客戶端憑據流可以涉及更強的憑據，例如 JWT 客戶端斷言或相互 TLS - 如本高級教程中所示。

索賠

在您的系統中，您應該將授權所需的域特定數據映射到每個客戶端 ID。 這可能包括對產品的特定國家/地區訪問或對您的場景有意義的任何內容。

然后，該數據可以在發布時包含在訪問令牌中，或者在首次收到訪問令牌時進行查找，然后緩存以用於具有相同令牌的后續請求。 我的授權博客文章的第 3 步在這里解釋了幾個設計模式。

API 請求

客戶端如何獲取 API 請求中的數據很有趣：

• 呼叫者是否擁有所有國家/地區的數據？ 如果是這樣，讓他們在 API 請求期間通過國家/地區參數選擇他們想要的數據。

• 如果 API 客戶端永遠無法查看某個國家/地區的數據，則表明至少在某些情況下，每個國家/地區需要不同的客戶端。

概括

根據對這些公司有意義的內容來定義客戶。 避免客戶端激增，以便管理同一數據所有者的訪問權限。 確切的解決方案取決於您的領域特定要求。 OAuth 是一個旨在適應的框架。

Answer 2

如果您的整個現有數據模型孤島都按照帳戶的概念划分“國家/地區”，那么每個帳戶的一組憑據可能是最簡單的。

但在我看來，您的數據模型並沒有完全捕捉到您的實際業務。 在我看來，您有一個“客戶/客戶”的概念，可以訪問多個“帳戶”中的一個，每個帳戶代表一個國家/地區。

因此，一種更正確的建模方法可能是構建您的 API，以便單個 API 客戶端可以訪問所有相關帳戶，並且您的 API 可能應該進行結構化，以便以某種方式傳遞accountId的想法（通常在 URL 中）用於 REST api）。 例如，每個 API 端點都可以以/account/123為前綴。

對我來說，這更像是一個數據建模和 API 架構問題，而不是任何特定於 OAuth2 的問題。