OAuth2：客户端凭据流答案

【问题标题】：OAuth2: Client Credentials flowOAuth2：客户端凭据流
【发布时间】：2021-12-22 03:42:40
【问题描述】：

问题：我目前正在努力为客户端提供一个 REST Api（在这种情况下，客户端不是订购文章的普通最终用户，而是与我的系统通信的客户端的 Web Api）。为了在我的系统中订购不同的产品，每个客户可能分别在每个国家/地区拥有多个帐户。身份验证是通过将客户端的 WebApi 应用程序验证到我的系统（机器对机器）来完成的。所以看起来这应该使用基于文章https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios#scenarios-and-supported-authentication-flows 的 OAuth2 Client Credentials Flow 来完成，但我对每个国家/地区的客户帐户问题分别表示怀疑。

问题：这应该通过为每个国家/地区的每个客户帐户分别创建一个 ClientId 和 ClientSecret 来解决，或者，但是，应该创建一个客户帐户，而国家应该由客户在每个请求中发送到 Api 或之前将国家/地区添加为访问令牌的范围或声明。此外，我不确定在这种情况下 Client Credentials Flow 是否是一个不错的选择，因此我将非常感谢任何建议。

【问题讨论】：

一旦您不想将一个客户端与另一个客户端的活动关联起来，他们应该有自己的 client_id/secret 对。

标签： oauth-2.0 oauth azure-ad-b2c

【解决方案1】：

客户

理想情况下，每个客户公司都应该有一个用于获取访问令牌的客户凭证。在某些情况下，例如当有不同的法律细分时，可以扩展。默认情况下使用单个值，但您需要了解您的客户。

如果需要，公司之间的客户端凭据流可能涉及更强的凭据，例如 JWT 客户端断言或 Mutual TLS - 如 this advanced tutorial。

索赔

在您的系统中，您应该将授权所需的域特定数据映射到每个客户端 ID。这可能包括特定国家/地区对产品的访问权限或对您的方案有意义的任何内容。

然后可以在颁发时将这些数据包含在访问令牌中，或者在第一次收到访问令牌时进行查找，然后缓存以用于具有相同令牌的后续请求。我的Authorization Blog Post 的第 3 步在这里解释了几个设计模式。

API 请求

客户端如何在 API 请求中获取数据很有趣：

调用者是否拥有所有国家/地区的数据？如果是这样，让他们在 API 请求期间通过国家参数选择他们想要的数据。
如果 API 客户端永远无法查看某个国家/地区的数据，这表明至少在某些情况下您需要每个国家/地区的不同客户端。

摘要

根据对这些公司有意义的方式来定义客户。避免客户端激增，以便管理同一数据所有者的访问权限。确切的解决方案取决于您的特定领域要求。 OAuth 是一个可以适应的框架。

【讨论】：

【解决方案2】：

如果您的整个现有数据模型孤岛通过帐户的概念“国家”，那么每个帐户的一组凭据可能是最简单的。

但在我看来，您的数据模型并没有完全捕捉到您的实际业务。在我看来，您有一个“客户/客户”的概念，可以访问多个“帐户”中的一个，每个帐户都代表一个国家/地区。

因此，一种更正确的建模方法可能是构建您的 API，以便单个 API 客户端可以访问所有相关帐户，并且您的 API 可能应该构建为以某种方式传递accountId 的想法（通常在 REST API 的 URL 中）。例如，每个 API 端点都可以以 /account/123 为前缀。

对我来说，这更像是一个数据建模和 API 架构问题，而不是任何特定于 OAuth2 的问题。

【讨论】：