自托管玩家的统一 OIDC + Passkey 认证网关

自托管开源软件用户长期缺乏现代身份认证。Joplin 用户在 ownCloud 或 Nextcloud 上自托管同步时，发现 "ownCloud only supports this authentication method"（OIDC），但 Joplin 不支持，只能被迫换方案；Mastodon 用户抱怨 "it still relies on passwords as primary authentication"，Passkeys 只能作为第二因素；还有 Mastodon 用户希望实例能成为 OpenID 提供者，摆脱对 Facebook、Google 这类集中式身份提供商的隐私依赖。这些请求分散在不同项目里，但指向同一个缺口：自托管生态缺少一个统一的、支持 Passkey 的身份层。

自托管（self-hosted）爱好者与小型实例管理员：运行 Nextcloud/ownCloud + Joplin 同步的个人用户，以及运营中小型 Mastodon 实例的管理员。这是一个规模有限但活跃的开源社区人群，付费能力未经验证。

自托管 OIDC 提供者：部署一个标准 OAuth 2.0 / OpenID Connect 服务，让 Mastodon 实例、Joplin 同步等场景直接接入； Passkey 优先登录：用 WebAuthn 作为主认证方式，密码仅作降级选项； 下游应用适配器：为 Joplin（ownCloud/Nextcloud 同步）、Mastodon 等提供现成的对接配置或上游 PR； 统一账户目录：一个账户管理所有自托管服务的身份，避免每个工具各建一套密码。 AI 在其中主要起辅助作用（配置生成、文档问答），核心是协议工程而非模型能力。

Passkey 生态正在成熟（信号中引用了 passkeys.dev 的现成库，且 Mastodon 已把 WebAuthn 作为第二因素），补齐主认证一步的技术门槛大幅下降；同时信号 3 显示用户对 Facebook、Google 等集中式身份提供商的隐私担忧在持续。

第一版只做：自托管 OIDC 提供者 + Passkey/WebAuthn 登录 + OAuth 2.0 下游应用接入。明确不做：修改 Joplin 或 Mastodon 源码本身（它们是否合并上游 PR 不受控制）、企业目录集成（LDAP/AD）、多租户 SaaS。

平台依赖：核心价值取决于 Joplin、Mastodon 等项目是否接受 OIDC 对接或 PR，上游不合并则方案失效； 开源竞争：Keycloak、Authentik 等成熟开源 IdP 免费可用，差异化空间窄； 付费意愿缺失：三个信号均为 willingness_to_pay: none，社区用户习惯免费方案，商业化路径不明； 维护负担：下游应用版本迭代快，协议适配需要长期跟进。