如何使用 OIDC/OAuth 保护 API

mat*_*hew 5 oauth oauth-2.0 openid-connect

我试图更好地理解如何利用 OIDC/OAuth 来保护 Restful API,但我总是在术语中迷失。另外,当我研究这个问题时,大多数答案都是针对单页应用程序的,因此就这个问题而言,假设 API 不会用于 SPA。

假设:

  • 客户将访问 Restful API 来与 <Service> 交互。
  • 预计客户将在自己的系统中创建自动化脚本或自定义应用程序来调用 API。
  • 设置完成后,预计不会有真人在每次调用 API 时提供凭据。
  • <Service> 使用第三方 IDP 来存储和管理用户。
  • 第三部分 IDP 实现 OIDC/Oauth,这就是它应该集成到 <Service> 中的方式

问题:

  • 在这种情况下应使用什么 OIDC/OAuth 流程?
  • 应向客户提供什么凭证?客户端 ID/客户端秘密还是其他什么?
  • 可以/应该使用哪些令牌来传达有关“用户”的信息?例如他们是谁/他们能做什么。
  • 应该如何验证这些令牌?
  • 您能给我指出任何解释这个特定用例的好图表/资源吗?
  • 我是否遗漏了工作流程中的任何重要内容?

Gar*_*her 3

如果我没有误解你的话,听起来这些就是要求。该解决方案不仅包含您自己的代码,而且更多的是一个数据建模问题,而不是 OAuth 问题。

R1:您的公司向业务合作伙伴提供 API

R2。业务合作伙伴从自己的应用程序中调用它,他们可以按照自己认为合适的方式进行开发

R3。用户身份验证将由每个业务合作伙伴管理,从而为每个用户提供唯一的 ID

R4。你需要将这些用户ID映射到你自己系统中的用户+资源

开放认证

合作伙伴应用程序应使用客户端凭据流来获取访问令牌以调用 API。每个业务合作伙伴都会为其用户组使用不同的凭据。

使用您自己的 IDP 来存储用户似乎没有意义,因为您似乎与实际的最终用户没有身份验证关系。

默认情况下,颁发给业务合作伙伴的访问令牌不是特定于用户的。用于识别用户的自定义声明可能包含在访问令牌中 - 这必须以自定义方式开发,例如通过自定义标头,因为它不是客户端凭据流的一部分。

访问令牌将以标准 OAuth 方式进行验证,以识别合作伙伴 - 以及可能的最终用户。

数据

在您自己的系统中对用户进行建模以拥有这些字段,然后存储映射到用户 ID 的资源(例如订单):

  • 用户ID(您生成的值)
  • 合作伙伴 ID(用户所属公司)
  • 外部用户 ID(合作伙伴易于提供的 ID)

通常,每个合作伙伴还会在您的数据库表之一中拥有一个条目,其中包括客户 ID、名称等。

如果您无法在访问令牌中包含自定义用户 ID 声明,合作伙伴必须告诉您他们在调用 API 时正在对哪个用户进行操作,并提供外部用户 ID:

  • 发布/用户/2569/订单

您的 API 授权需要确保来自合作伙伴 A 的调用无法访问来自合作伙伴 B 的任何资源。在上述数据中,您拥有启用此功能所需的所有字段。

概括

因此,感觉您需要根据从合作伙伴应用程序后端调用它们的方式为自己的 API 定义接口。希望以上提示对此有所帮助。