authentication - REST API 的认证和授权设计

Question

我正在设计一个带有 REST API 的系统。REST API 将使用 Spring Boot 实现。该系统应管理员工、产品、订单信息。它可以单独使用，也可以作为现有产品生态系统的一部分使用。我正在寻找一些资源（书籍、博客、在线课程等）来帮助我决定如何实现身份验证和授权。

如果系统作为独立产品使用，如何做到这一点非常明显。用户凭证/授权数据可以存储在产品/员工和其他数据旁边的同一数据库中。

当应用程序是某些现有生态系统的一部分时，我不确定如何处理所有事情。如果：

1. 有人想重用现有的用户数据存储进行身份验证或第三方服务，如 Okta 或 Auth0。
2. 使用现有数据构建授权规则。例如，如果某人属于某个用户组，则授权该人修改产品数据。

我正在考虑 Oauth2+OIDC 解决方案。例如 Okta 允许添加基于表达式的声明。用户组也可以作为声明提供。看来 Okta 可能是身份验证和授权信息的来源。我不确定这是否是使用 Oauth2 和 OIDC 的正确方法？以这种方式存储授权数据的潜在缺陷是什么？我检查了 Keycloak，它似乎是授权数据。可以存放在那里。因此，在授权服务器中管理此类数据并不是一种不寻常的做法。也许我应该只使用 Oauth2/OIDC 进行身份验证？授权数据（分配的角色、组等）可以存储在我的应用程序数据库中。应用程序应提供管理信息的方法。

我想获得有关该主题的一些建议或信息来源。谢谢你。

标签： authenticationspring-securityoauth-2.0authorizationopenid-connect

Answer 1

我的目标是保持 OAuth 数据相当小 - 授权服务器 (AS) 通常只需要几个字段来管理登录，例如名称/电子邮件和生成的用户 ID。

当数据成为特定领域时，它可能会成为在 AS 中管理它的负担，而在您的产品数据中，更容易启动自定义 UI 等。

相反，AS 可以在向 API 发出令牌期间联系以在访问令牌中包含重要声明 - 例如角色等。同时，您不希望向 Internet 客户端公开详细的访问令牌。

Curity 网站上有一些很好的资源来满足上述要求——这里有几个链接：

• IAM 入门
• 理赔最佳实践