oauth-2.0 - 如何使用 OIDC/OAuth 保护 API

Question

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

假设:

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

问题:

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

Answer 1

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

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

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

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

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

OAUTH

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

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

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

访问 token 将以标准的 OAuth 方式进行验证，以识别合作伙伴 - 可能还有最终用户。

数据

在您自己的系统中为用户建模以具有这些字段，然后存储与用户 ID 映射的资源(例如订单):

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

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

如果您不能在访问 token 中包含自定义用户 ID 声明，合作伙伴必须在调用 API 时告诉您他们正在操作的用户，并提供外部用户 ID:

• POST/users/2569/orders

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

总结

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