验证器首先必须确保所提供的令牌确实是可用于客户端认证的有效 Bearer 令牌。正确做法依赖具体提供方，但通常涉及以下两种方式之一：通过密码学操作证明令牌由受信任方创建（离线校验），或将令牌提交给受信任方，由其代为校验（在线校验）。

在线校验通常通过 OAuth Token Introspection 实现，验证器模块所需步骤更少，并且在令牌被盗用或错误签发时可进行集中吊销。但这要求模块在每次认证尝试时至少执行一次网络调用（且都必须在配置的 authentication_timeout 内完成）。此外，提供方可能并不提供供外部资源服务器使用的内省端点。

离线校验要复杂得多，通常要求验证器维护提供方的受信任签名密钥列表，然后同时检查令牌的密码学签名及其内容。实现必须严格遵循提供方说明，包括对签发者（“该令牌来自哪里？”）、受众（“该令牌给谁用？”）和有效期（“该令牌何时可用？”）的全部验证。由于模块与提供方之间没有通信，使用该方法无法集中吊销令牌；离线验证器实现可以考虑限制令牌有效期的最大长度。

如果令牌无法通过校验，模块应立即失败。若 Bearer 令牌并非由受信任方签发，后续认证/授权都没有意义。

接下来，验证器必须确保终端用户已授权客户端代表其访问服务器。这通常需要检查分配给令牌的授权范围，以确认其覆盖当前 HBA 参数所要求的数据库访问权限。

该步骤的目的是防止 OAuth 客户端在虚假前提下获取令牌。如果验证器要求所有令牌都必须携带覆盖数据库访问的授权范围，提供方在流程中就应明确提示用户授予该访问权限。这样一来，如果客户端本不应使用其凭据连接数据库，用户就有机会拒绝该请求。

也可以通过部署架构的带外知识在没有显式授权范围的情况下完成客户端授权，但这样会让用户无法参与授权过程，用户将无法发现部署错误，而此类错误也可能被静默利用。如果不提示用户授予额外授权范围，则对数据库的访问必须被严格限制为仅允许受信任客户端 ^[17]。

即使授权失败，模块也可以选择继续从令牌中提取认证信息，用于审计和调试。

最后，验证器应确定该令牌对应的用户标识符，可通过向提供方请求此信息或直接从令牌中提取，然后将该标识符返回给服务器（服务器随后会基于 HBA 配置作出最终授权决策）。该标识符可在会话中通过 system_user 获取；若启用 log_connections，也会被记录到服务器日志。

不同提供方可能记录多种不同的终端用户认证信息，通常称为声明（claims）。提供方一般会说明哪些声明足够可信，可用于授权决策，哪些不行。（例如，将终端用户全名作为认证标识符通常并不明智，因为很多提供方允许用户任意修改显示名称。）最终应使用哪个声明（或哪些声明的组合），取决于提供方实现和应用需求。

还需注意，通过启用用户名映射委派也可以实现匿名/化名登录；参见第 50.1.3 节。

模块不应将令牌或令牌片段写入服务器日志。即使模块判定令牌无效，也应遵循此原则；否则，诱导客户端与错误提供方通信的攻击者可能从磁盘中取回该令牌（该令牌本身可能对正确提供方仍然有效）。

若实现需要通过网络发送令牌（例如与提供方进行在线令牌校验），必须认证对端并确保使用强传输安全。

模块可以使用与标准扩展相同的日志功能；但在连接认证阶段，向客户端发出日志条目的规则存在细微差异。一般来说，为避免向未认证客户端泄露信息，模块应以 COMMERROR 级别记录校验问题并正常返回，而不是使用 ERROR/FATAL 来展开调用栈。

模块必须保持可被信号中断，这样服务器才能正确处理认证超时和来自 pg_ctl 的停机信号。例如，套接字上的阻塞调用通常应替换为能够在没有竞争条件的情况下同时处理套接字事件与中断的代码（见 WaitLatchOrSocket()、WaitEventSetWait() 等），且长时间运行的循环应定期调用 CHECK_FOR_INTERRUPTS()。不遵循该建议可能导致后端会话失去响应。

OAuth 系统测试的完整范围远超本文档讨论范围，但至少应将负向测试视为强制要求。设计一个允许已授权用户登录的模块很容易；该系统的核心目的在于阻止未授权用户进入。

验证器实现应在文档中说明针对每个终端用户向服务器报告的认证 ID 的内容和格式，因为 DBA 可能需要据此构造 pg_ident 映射。（例如，它是邮箱地址？组织 ID 号？还是 UUID？）还应在文档中说明该模块在 delegate_ident_mapping=1 模式下是否可安全使用，以及为此需要哪些额外配置。