本篇要回答的问题：如何给 QPaint 真正引入帐号与授权体系？为什么"基于 OpenID Connect 提供帐号系统 + 基于 OAuth 2.0 实现 Open API"是理想方案，又为什么应该直接复用开源项目 dex 而非自己造轮子？
四部曲第三部讲清了帐号、授权与 OAuth 2.0 的逻辑。本讲是实战的收官：把概念落到 QPaint，但核心结论是"这块业务无关、别造轮子"——直接评估并复用 CoreOS 的 dex，把精力还给业务本身。
三种落地路线的取舍
| 路线 | 做法 | 评价 |
|---|---|---|
| 自建帐号库 | 用户名+密码登录 + Cookie Session | 最常规，但封闭、第三方难接入 |
| 遵循 OAuth 2.0 | 提供标准授权协议 | 第三方可快速接入，无需研究你自创的授权 |
| 复用 OpenID（微信/支付宝等） | 让用户快速登录免注册 | 降低注册门槛 |
关键判断：理想方式是基于 OpenID Connect 协议提供帐号系统 + 基于 OAuth 2.0 协议实现 Open API 体系。这个选择与业务无关，所以先评估有无现成开源项目，而非自己重造。
dex：联邦 OpenID 提供方
CoreOS 团队的 dex（A federated OpenID Connect provider）正是想要的：
| 角色 | 说明 |
|---|---|
| 上游 Upstream IdP | 各类主流 OpenID Provider，以**插件（Pluggable Connector）**方式接入 → 故称"联邦 OpenID" |
| dex 自身 | 屏蔽上游差异，对外统一提供 OpenID Connect + OAuth 2.0 |
| 下游 Client app | 只需对接 dex 一次，协议细节由 dex 处理 |
dex 的 Connector 支持情况：
| Connector 类型 | 举例 |
|---|---|
| 统一 OIDC Connector | Google、Salesforce、Azure 等支持 OpenID Connect 的 |
| 独立 Connector | Github 等不走 OIDC 的，各实现一个 |
| 其他协议 | SAML 2.0、LDAP（非重点，仅给参考链接） |
关键洞见：不同上游会带来细节差异（有的不支持 Refresh Token，有的 ID Token 无 groups 字段）；且 dex 不支持国内主流的微信、支付宝——但靠开放插件机制可"依葫芦画瓢"自己实现。“想到点子不难，架构设计才见高下”（对比 union 项目）。
OpenID Connect 的关键扩展：ID Token
dex 底层 Provider 多样，对外却统一输出标准协议。OpenID Connect 作为 OAuth 2.0 的扩展，最重要改进是引入身份令牌（ID Token）：
| 令牌 | 用途 | 是否含身份信息 |
|---|---|---|
| Access Token | 访问资源 | 否 |
| Refresh Token | 续期换新 Access Token | 否 |
| ID Token | 验证用户身份 | 是（一个 JWT，可 decode + verify） |
关键判断：OAuth 2.0 只关心授权，Access/Refresh Token 都不含身份（Identity）信息，没法作 OpenID Provider；ID Token（JWT）正是补上这块身份信息，让 dex 能当 OpenID Provider。
dex 是可执行程序而非包，dex config.yaml 启动（如 config-dev.yaml 用 mock、config-ldap.yaml 基于 LDAP）。
QPaint 对接 dex
有了 dex，QPaint 几乎不用自己开发，只需用现成 SDK 对接：
| 需求 | 现成方案 |
|---|---|
| OAuth 2.0 客户端 | Go 准官方 golang.org/x/oauth2 |
| OpenID Connect 客户端 | CoreOS go-oidc |
| 对接说明 | dex 的 using-dex.md 文档 |
总结
实战收官的核心是"别造帐号授权的轮子"：用 OpenID Connect 提供帐号、OAuth 2.0 提供 Open API，背后直接复用 dex——它以联邦插件屏蔽上游差异、统一对外输出标准协议，并用 ID Token（JWT）补齐 OAuth 缺失的身份信息。QPaint 只需 oauth2 + go-oidc 两个 SDK 即可接入，把关注重心彻底交还给业务本身。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| OpenID Connect | OAuth 2.0 的扩展，引入 ID Token 提供身份信息 |
| ID Token | 一个 JWT，可 decode + verify，承载用户身份 |
| dex | 联邦 OpenID Connect Provider，插件式接入多上游、统一输出标准协议 |
| Pluggable Connector | dex 接入各上游 OpenID 的插件机制 |
| 联邦 OpenID | 多个上游 IdP 经插件汇聚、对外统一授权 |
一句话速记
帐号授权业务无关——用 OpenID Connect 提供帐号、OAuth 2.0 提供 Open API，直接拿 dex（联邦插件 + 统一协议 + ID Token 补身份），QPaint 只接 SDK 不造轮子。
几条值得记住的判断
- 与业务无关的能力，第一反应是找开源复用而非自研。
- OAuth 2.0 缺身份信息，OpenID Connect 用 ID Token（JWT）补上才能做 OpenID Provider。
- dex 的价值在于用插件屏蔽上游差异、对外只露标准协议——这正是好架构与"凑功能"的差距所在。
思考题
dex 的精髓是"插件屏蔽差异、对外统一标准协议"。回到你的系统：那些与业务无关的通用能力（帐号、授权、通知、支付），你是自己重复造轮子，还是抽象出一层统一接口、用插件接入多家实现？哪一处最该被"dex 化"？
