PG 在什么场景需要 OAuth 身份验证方法?

PG 在什么场景需要 OAuth 身份验证方法?

PG 18 新版本提供了OAuth身份验证方法, 但是这个验证方法在什么场景使用呢? OAuth配置门槛其实蛮高的, OAuth该如何使用? 下面来看一下OAuth的作者之一, 来自EDB的 Jacob Champion 分享的文章. 以下内容翻译自: https://www.enterprisedb.com/blog/developing-oauth 同时, 对于如何使用OAuth、OAuth原理、周边工具开发等可以参考他的同事 Guang Yi Xu 的文章. 第一部分： 探索 PostgreSQL 18 OAuth2 身份验证的工作原理

• https://www.enterprisedb.com/blog/preview-postgresql-18s-oauth2-authentication-1-explore-how-it-works

第二部分： 使用 Rust 编写自定义验证器

• https://www.enterprisedb.com/blog/preview-postgresql-18s-oauth2-authentication-2-building-custom-oauth2-validator-rust

第三部分： 教 PostgreSQL proto 3 客户端库使用 OAUTHBEARER

• https://www.enterprisedb.com/blog/preview-postgresql-18s-oauth2-authentication-3-enhancing-postgresql-client-library-speak

为什么需要 OAuth 身份验证方法？

Postgres 的默认身份验证方法 SCRAM 拥有坚实的加密基础，并且不断改进，将继续成为机器间通信(应用程序)和少量人工客户端(如: DBA、开发者、数据分析师等)的全面卓越选择。但我认为它不太适合大型人工系统，因为维护工作最终归结为为每个可能的（用户、集群）对进行单独的密码管理。对于那些试图保护包含多个数据库的系统、与数百或数千人沟通的人来说，说“我希望我能将所有这些信息都放在一个地方”是很自然的。 不幸的是，Postgres 目前支持的第三方身份验证解决方案有点混乱：

• LDAP，它只是以纯文本形式发送密码并希望获得最佳结果；
• Kerberos 作为一个整体解决方案很难审计和保护，跨平台存在互操作性问题，感觉就像是一个逐渐失去动力的架构；
• TLS 客户端证书，虽然我非常喜欢它们！但对于大多数人来说，在实践中很难维护，他们相当不愿意运行证书颁发机构。
• （还有 RADIUS。我无法对此发表评论；我从未见过它在实践中部署。）

当我刚开始开发 OAuth 补丁集时，我刚开始厌倦某个 LDAP 部署带来的客户支持问题。所有数据库集群定期运行的、用于同步 Postgres 角色和目录的脚本，已经开始导致 LDAP 服务器本身崩溃。我迫切地希望彻底消灭这种架构。 OAuth 在多个方面取得了进步。客户端无需关心用户如何进行身份验证，因此您可以采用最新的密码/密钥/MFA 最佳实践，而 Postgres 无需知晓。 客户端身份与用户身份保持分离 ，因此允许程序代表您连接到数据库并不会隐式地赋予该程序以您的名义执行任何其他操作的能力。而真正赋予客户端权力的东西 —— OAuth 令牌 —— 是有时间限制的，并且（通常）具有自描述性，因此在 Postgres 内部运行的 OAuth 验证器可以做出安全的决策，而无需始终 ping 中央服务器。 现在，到了这篇文章的这个阶段，我可以撒个谎，比如“OAuth 解决了我们所有的问题！”这样的话，肯定会让大家当众嘲笑我。OAuth 本身 也乱成一团。它就像一个迷宫，里面充斥着各种规范、草案和实现，声称兼容，但在某些极端情况下却无法互操作，因为留给读者思考的部分太多了。坦白说，对于 Web 规模的技术来说，这种情况很常见，所以你完全有理由好奇我为什么对此感到满意。 尽管存在互操作性问题、规范不足和一些失误，我对实施 OAuth 感到很满意，因为在我看来，OAuth 就像一个生态系统，由来自不同组织的许多人组成，他们致力于各种重要的用例，并基于 HTTPS 和公钥加密等可靠的开放技术，不断改进这个许多人赖以保护自身资产安全的系统。作为一名 Web 出身的人，我认为这一切似乎是一个长期的良策。 我的水晶球已经破损不堪，所以十年后回头看的时候，我可能会发现它已经过时了。但就目前而言，我对此持乐观态度。而且我恰好喜欢阅读 IETF 规范并将其整合到软件中。所以我开始着手做这件事。

为什么这对开发者、客户和最终用户来说都是一件令人兴奋的事情？

我对 OAuth 感到兴奋，因为它朝着一个生态系统迈进了一步，在这个生态系统中，我们的决策不再基于用户名，而是更多地基于用户权限的声明。我认为以这种方式运作的系统更容易扩展。它还开辟了一些小众用例，比如匿名访问，在这种情况下，你知道最终用户可以访问，但你不必知道用户是谁。 对于客户来说，我认为有些DBA会很乐意摆脱同步脚本和其他定制基础设施，因为这些基础设施需要连接他们的 SSO 服务器和数据库。无论如何，这并非一蹴而就，但总有一个出口。随着验证器实现的发展和成熟，我认为我们可以达到这样的程度：数据库管理员可以按照 自己希望在组织中工作的 方式设置身份验证，然后把时间花在其他更有趣的事情上。 至于最终用户 …… 最终用户真的会“兴奋地”登录吗？我不确定。但我确实希望，对于那些已经需要遵守其组织身份验证设置的用户来说，此功能有助于减少摩擦，并允许他们在更多地方使用他们已经熟悉的身份验证工具。（如果不是这样，我希望在邮件列表中听到它，以便我们可以改进 PG v19 的功能！）

你知道什么更令人兴奋吗？未来的改进！它们是什么？

以下是我在 v18 实现中未能实现的一些功能，但我认为最终人们会真正想要的。（它们几乎都与 OAuth“流程”相关：Postgres 客户端通过这些流程与 OAuth 提供程序通信，以确定您的身份以及您愿意授予它哪些权限。）

• 我希望能够切换流程而无需编写自定义代码。在 PG18 中，您可以为自己的程序提供自己的客户端流程，但您不能在不开放其他实用程序的情况下将该流程插入到其他实用程序中。这对每个人来说都不够，我们需要找到一种方法来（安全地）允许用户切换到他们自己的实现。
• 我希望我们交付的流程能够安全地缓存令牌。就像没有人愿意在电脑上执行每个操作时都输入密码一样，也没有人愿意每次连接时都重新执行客户端流程。自定义流程（见上文）始终可以实现自己的缓存，但我们应该提供一些可供社区默认使用的功能。我们只需要开发一个安全的地方来存放这些令牌……
• 我想要一个内置的机器对机器流程。PG18 流程是为拥有物理设备的人设计的，因此，如果自治脚本和服务想要使用与人相同的 OAuth 提供程序，就必须实现自定义代码。（这些脚本和服务在 Postgres 中还有其他强大的非 OAuth 选项可用，但对于一些数据库管理员来说，进一步简化和统一他们的设置是有意义的。）
• 我希望将令牌绑定到其客户端。如果令牌在传输过程中泄露或被盗，它可以用来冒充客户端，直到过期。（这比明文密码还是有改进的，但效果并不好。）自从我开始开发这个功能以来，已经出现了一些解决这个问题的规范，我认为我们很快就需要朝着这个方向努力。
• 我想要一个内置的验证器实现。我很失望，因为在 v18 中无法为 OAuth 提供完全“内置”的体验。我不确定这是否真的可行，除非一些主流提供商就其发行的令牌的大量约定达成一致，但我仍抱有希望。我可以梦想。

所以还有很多工作要做。但是，在没有用户的情况下开发一项功能非常困难，我期待收到实际使用用户的反馈。如果您有任何反馈，无论是关于下一步的想法，还是关于您目前不喜欢什么的想法，请在邮件列表中告诉我！