OAuth2授权码流程中资源所有者认证的用户凭证存储方案探讨

我正在搭建OAuth2**授权码流程（code flow）**的演示项目，需要实现客户端、资源服务器及认证服务器。我见过的所有实现中，资源所有者在批准客户端授权请求前，都需在认证服务器登录——这是认证服务器识别资源访问请求发起者的必要步骤。

我意识到这一步与OAuth2或OpenID Connect协议无关：OAuth2定义了资源所有者授权第三方客户端访问自身数据的方式，但认证服务器的登录流程属于实现细节（甚至可采用无密码方式）；OpenID Connect是OAuth2的扩展，核心是向客户端提供必要的认证信息。

两种基于用户凭证的认证服务器登录实现方案 #

• 方案一：认证服务器可访问包含如下结构的数据源：

  id, username, hashed_password
  

  资源所有者登录时，认证服务器直接通过该数据源验证凭证。此方案的问题在于，需要维护该数据源与资源服务器存储中用户的映射关系。

• 方案二：用户相关数据（包括用户名和哈希密码）仅存储在资源服务器中。认证服务器需查询资源服务器来验证资源所有者登录时提交的凭证。除了额外的往返时延（RTT）成本外，将认证信息存储在资源服务器中似乎并不合适——毕竟用户密码属于安全类非功能需求，我是否误解了资源服务器的定位？

核心疑问 #

这两种方案是否合理？哪一种更符合OAuth2模型？主流OAuth2服务通常如何处理此问题？

补充：ChatGPT的回答 #

在等待答复期间，我咨询了ChatGPT，它认同第二种方案并不正确，解释如下：

在OAuth 2.0协议场景下，资源服务器不应存储用户密码。标准OAuth 2.0流程中，资源所有者（用户）的认证由认证服务器负责：认证服务器需验证用户凭证（如用户名和密码），并代表用户向客户端（应用）颁发访问令牌。

资源服务器只需接收并验证客户端提供的访问令牌，判断客户端是否有权访问请求的资源；同时，认证服务器通常会在访问令牌的载荷中包含用户信息（如用户ID或邮箱），资源服务器可借此识别用户并关联自身托管的用户数据。资源服务器无需知晓用户密码，因为它不执行认证操作。

认证服务器可存储用户邮箱和经过安全哈希加盐处理的密码，并关联唯一用户ID。该用户ID可用于将资源服务器存储的用户数据与认证服务器颁发的访问令牌关联起来。

显然，我期待更全面且可靠的答复，最好包含相关资料来源。

内容的提问来源于stack exchange，提问作者Marco Luzzara