[GH-ISSUE #1063] [Feature] Support OAuth Login / 支持 OAuth 登录 #718

New issue

Open

opened 2026-03-03 01:05:28 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 01:05:28 +03:00

Owner

Originally created by @Allenyou1126 on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/certimate-go/certimate/issues/1063

Description / 功能描述

如题，为 Certimate 增加 OAuth 登录支持。

虽然 #540 已经提过了，但是感觉还是可以拿出来讨论一下。

具体可以参照 Wakapi 的实现，做以下功能：

已有的认证系统保留，默认启用原本的认证系统
增加配置项 / 启动参数，允许使用外置 OAuth 代替内置认证

Motivation / 请求动机

完善 Certimate 的管理支持，方便适配进更多的工作场景中（如多人协作，分别使用自己的账号登录，使用已有 SSO 系统统一管理）

Miscellaneous / 其他

由于时间原因，暂时无法做贡献，到 2026 年 2 月可以抽出时间来做相关实现，如果没人做的话我可以在 0.4.x 版本的基础上做，争取赶上 0.5.x 版本发布。

Contribution / 贡献代码

I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

Originally created by @Allenyou1126 on GitHub (Nov 26, 2025). Original GitHub issue: https://github.com/certimate-go/certimate/issues/1063 ### Description / 功能描述如题，为 Certimate 增加 OAuth 登录支持。虽然 #540 已经提过了，但是感觉还是可以拿出来讨论一下。具体可以参照 Wakapi 的实现，做以下功能： - 已有的认证系统保留，默认启用原本的认证系统 - 增加配置项 / 启动参数，允许使用外置 OAuth 代替内置认证 ### Motivation / 请求动机完善 Certimate 的管理支持，方便适配进更多的工作场景中（如多人协作，分别使用自己的账号登录，使用已有 SSO 系统统一管理） ### Miscellaneous / 其他由于时间原因，暂时无法做贡献，到 2026 年 2 月可以抽出时间来做相关实现，如果没人做的话我可以在 0.4.x 版本的基础上做，争取赶上 0.5.x 版本发布。 ### Contribution / 贡献代码 - [x] I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

kerem added the

enhancement

label

2026-03-03 01:05:28 +03:00

kerem commented

2026-03-03 01:05:29 +03:00

Author

Owner

@fudiwei commented on GitHub (Nov 27, 2025):

OIDC / OAuth / SSO
多账号
多租户
权限控制
合规审计
etc.

这一类的需求我个人会统一称之为“企业级需求”，属于是长期会考虑（没有明确的 ETA）、但短期内不考虑的，换而言之，在此时此刻它们的优先级非常低。主要出于以下两点考虑：

个人精力有限。企业级需求通常复杂而灵活，因此需要花费大量时间来实现，但对于更为广大的中小型用户来说却很难因此受益。注意，这里的“有限”并不是完全指没有时间来贡献代码，因为我们欢迎并鼓励来自社区的开发者（我本人就是）参与贡献，但因为种种原因，并非所有贡献者都能从始至终参与，因而后期工作最终还是会落到维护者头上，在未来的迭代中如何扩展、如何测试等等问题都会带来很大的挑战。
技术选型限制。目前的后端框架是 PocketBase，我相信 @usual2970 最初选择它的最主要原因就是它适合 Startup，但它并不完全适用于企业级应用。以原文中提到的 OAuth 为例，Pocketbase 确实提供了相关能力，但并不易扩展、或者说其实现方案与主流实践有很大差异。在未来，很可能技术选型会发生重大变化，而过早地实现作为“基石”的企业级需求，会在日后产生很多技术负债。

这个 Issue 我暂时不会关闭，欢迎继续分享你的想法或建议。但注意，请不要提交与该 Issue 有关的 PR。正如我所言，它们的优先级很低，现在并不是接受它们的恰当时机。

@fudiwei commented on GitHub (Nov 27, 2025): - OIDC / OAuth / SSO - 多账号 - 多租户 - 权限控制 - 合规审计 - _etc._ 这一类的需求我个人会统一称之为“**企业级需求**”，属于是长期会考虑（没有明确的 ETA）、但短期内不考虑的，换而言之，在此时此刻它们的优先级非常低。主要出于以下两点考虑： 1. 个人精力有限。企业级需求通常复杂而灵活，因此需要花费大量时间来实现，但对于更为广大的中小型用户来说却很难因此受益。注意，这里的“有限”并不是完全指没有时间来贡献代码，因为我们欢迎并鼓励来自社区的开发者（我本人就是）参与贡献，但因为种种原因，并非所有贡献者都能从始至终参与，因而后期工作最终还是会落到维护者头上，在未来的迭代中如何扩展、如何测试等等问题都会带来很大的挑战。 2. 技术选型限制。目前的后端框架是 PocketBase，我相信 @usual2970 最初选择它的最主要原因就是它适合 Startup，但它并不完全适用于企业级应用。以原文中提到的 OAuth 为例，Pocketbase 确实提供了相关能力，但并不易扩展、或者说其实现方案与主流实践有很大差异。在未来，很可能技术选型会发生重大变化，而过早地实现作为“基石”的企业级需求，会在日后产生很多技术负债。 --- 这个 Issue 我暂时不会关闭，欢迎继续分享你的想法或建议。但注意，请不要提交与该 Issue 有关的 PR。正如我所言，它们的优先级很低，现在并不是接受它们的恰当时机。