PostgreSQL 18 的 OAuth 认证：如何设计安全的数据库连接方案？
题目与场景
你的团队准备把多租户分析平台升级到 PostgreSQL 18，希望应用使用 OAuth 2.0 bearer token 连接数据库，减少长期密码和人工轮换。请说明 PostgreSQL 18 的 OAuth 认证边界、连接握手、角色映射与上线迁移方案，并指出最容易造成权限扩大或 issuer 混淆的地方。
面试官考察什么
- 能否区分 OAuth client、authorization server、resource server 与数据库角色。
- 能否把
pg_hba.conf、validator、scope、map 和 libpq 参数串成完整数据流。 - 能否识别 discovery、issuer 精确匹配、TLS 与 token 生命周期风险。
- 能否设计可回滚的灰度迁移，而不是只说“把密码换成 token”。
澄清问题
- 连接方是人、后台服务，还是两者都有？不同主体决定 public 或 confidential client 的选择。
- 每个租户是否对应独立数据库角色？是否允许一个 token 代表多个角色？
- provider 是否提供标准 discovery 文档和 bearer token validator？
- 旧客户端能否继续使用 SCRAM，迁移期间的审计和回滚窗口多长？
30 秒回答
我会把 PostgreSQL 视为 resource server，把 libpq/psql 视为 OAuth client，把外部身份系统视为 authorization server；数据库本身不签发 token。服务端在 pg_hba.conf 中启用 oauth，配置精确的 issuer、scope 和 validator，必要时用 map 将外部身份映射到数据库角色。客户端通过 discovery 获取端点并提交 bearer token，服务端 validator 校验签名、issuer、受众、过期时间和 scope。上线先保留 SCRAM，按租户灰度、记录拒绝原因和角色映射，出现异常时关闭 OAuth 规则即可回滚。
深入拆解
1. 明确信任边界
PostgreSQL 18 提供 OAuth 认证方法，但不提供 authorization server。OAuth provider 负责授权和 token 签发，数据库负责验证 token 并决定是否允许连接。把数据库当作 OIDC 登录页或让数据库直接保存 refresh token，都会扩大责任边界。
2. 配置服务端规则
在 pg_hba.conf 中为目标网络和数据库增加 oauth 规则，并配置 issuer、scope、可选 validator 和 map。issuer 必须与 discovery 文档中的 issuer 标识逐字匹配；多个 validator 并存时应显式指定名称。规则顺序要先于宽泛的密码规则，避免请求被错误规则接管。
3. 处理发现与连接握手
libpq 使用 oauthissuer 访问 discovery 文档，再依据服务端要求获取 token。客户端的 oauthissuer 必须与 HBA 中的 issuer 一致；PostgreSQL 文档明确指出，不一致会导致连接失败，也能降低 mix-up attack 风险。连接字符串中不要把 token 写入日志、进程参数或持久化配置。
4. 做 token 与角色校验
validator 至少要检查签名、issuer、有效期、受众和所需 scope，并返回可审计的外部身份。没有 map 时，验证后的用户名必须与请求角色名相同；有多租户映射时，映射表应采用最小权限和默认拒绝。delegateidentmapping 会跳过标准 pg_ident.conf 映射，只能在 validator 自己完成完整授权判断时使用。
5. 迁移与回滚
先在非生产环境验证 provider discovery、TLS、scope 和失效 token，再为一小组服务增加 OAuth HBA 规则。双轨期间分别统计成功率、过期 token、issuer 不匹配和角色映射拒绝。确认连接池、作业和运维脚本都能刷新 token 后扩大范围。回滚只需撤销 OAuth 规则或切回 SCRAM，保留旧凭据直到所有连接池完成切换。
高质量示范答案
我会先画出四个主体：服务进程是 client，外部身份平台是 authorization server，PostgreSQL 是 resource server，数据库角色是本地授权对象。服务端用 pghba.conf 的 oauth 方法指定 issuer、scope 和 validator，并把 token 身份映射到租户角色；不使用 delegateidentmapping，除非 validator 能证明角色授权。客户端只保存短期 token 获取所需的安全配置，使用 oauthissuer 触发 discovery，强制 TLS 并禁止在日志中记录 token。灰度阶段保留 SCRAM 规则，按租户和连接池逐步切换，监控 issuer、scope、过期和映射失败；发现错误时删除 OAuth 规则即可回滚。这样既利用 PostgreSQL 18 的原生验证能力，也把身份签发、数据库授权和迁移控制分开。
常见错误
- 说 PostgreSQL 会签发 OAuth token，混淆 resource server 与 authorization server。
- 只验证 JWT 签名，不验证 issuer、受众、过期时间或 scope。
- 认为 issuer 只要域名相同即可，忽略 discovery 中的逐字匹配。
- 直接启用
delegateidentmapping，却没有说明 validator 如何做角色授权。 - 将 bearer token 放入连接日志、错误追踪或长期环境变量。
- 一次性删除 SCRAM，导致连接池和批处理任务无法回滚。
追问与回答
issuer 为什么必须精确匹配？
客户端会依据 issuer 构造 discovery URL，并将返回文档中的 issuer 与配置比较。大小写、格式或路径变化都可能导致失败；严格比较也能阻止客户端被错误授权服务器诱导。
没有 map 时如何决定数据库角色？
验证器得到的用户名必须与请求连接的角色名完全一致。多租户环境通常需要显式 map，并让不存在的映射默认拒绝，避免 token 身份自动落入高权限角色。
OAuth 失败时如何保持可用？
保留短期有效的 SCRAM 回滚凭据，先按连接池灰度；监控按错误类型分组的失败率。必要时撤销 OAuth HBA 规则并恢复原规则，再修复 discovery、scope 或 validator 配置。