【问题标题】:Authentication and Authorization design for REST APIREST API 的认证和授权设计
【发布时间】:2021-05-14 11:58:34
【问题描述】:

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

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

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

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

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

我想就该主题获得一些建议或信息来源。 谢谢。

【问题讨论】:

    标签: authentication spring-security oauth-2.0 authorization openid-connect


    【解决方案1】:

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

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

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

    Curity 网站有一些很好的模式资源可以满足上述要求 - 这里有几个链接:

    【讨论】:

    • 谢谢,curity 有很多有用的信息。很好的资源。
    猜你喜欢
    • 2023-03-23
    • 1970-01-01
    • 1970-01-01
    • 2018-07-28
    • 2020-01-12
    • 1970-01-01
    • 1970-01-01
    • 2019-01-09
    • 1970-01-01
    相关资源
    最近更新 更多