好的，我终于有一个进行中的版本可以在此分享了
几点说明。
在初始实现中，我选择了 Google Apps 托管域名（hd）组这一稍显复杂的情况，因为我认为这有助于厘清各种可能的组合，例如需要处理来自提供商的特定于域名的组。
为了实现该用例，我还必须在认证阶段引入“二次授权”的新概念，以支持增量授权。我考虑过几种不同的实现方式来请求特定用户的组权限（即如果他们使用 hd 进行认证），而这种方式看起来最为可行。我承认这在这一方面可能比预期的改动更大，但或许值得讨论。
请注意，要实现 Google 托管域名组的情况，您需要授予 Google Apps 托管域名组中的非管理员成员委托管理员权限，以便列出他们的组（通过管理员目录 API）。实际上，有一个名为“组读取器（Groups Reader）”的“测试版”预建管理员角色非常适合此用途。详见 Prebuilt administrator roles | User management | Google Workspace Help
Google 实现已生效。如果您设置好并使用托管域名进行认证，您的 Google 托管域名组将出现在自动组成员资格设置中；如果选中了该托管域名组，您将被添加到对应的 Discourse 组中；如果该组被移除，您也会被移除（这两个操作都会被详细记录）；随后在该 Google 托管域名组中认证的用户将立即被添加。
具体细节从代码和测试用例中应该显而易见。您还会注意到，我最终添加了三个新表。我尝试过几种更“轻量级”的解决方案，但在处理用户关联组以及组关联组的更新时，它们最终都变得更加复杂且效率低下。为每个场景创建新表似乎难以避免。不过，我非常欢迎关于数据建模以及其他方面的建议。
还有一些技术待办事项（除了上述提出的概念/产品问题）。在此方面也欢迎提出建议：
- 或许将 associated_groups 的
label进行序列化（而不是在客户端建模）。 - 补充缺失的测试用例和 QUnit 测试。
- 或许将 user_associated_group / group_associated_group 的创建和销毁移至后台任务执行，因为当数量庞大时，这可能会很慢。