本篇要回答的问题：在给 QPaint"动真格"做帐号与授权之前，帐号（Account）和授权（Authorization）到底是什么、什么关系？为什么 To C 应用要选 Token 授权，OAuth 2.0 的角色、流程与授权码模式又是怎么回事？
四部曲第二部完成了底层多租户改造，但用的还是 mock 授权。本讲是第三部，先把帐号与授权的基础概念讲透、重点拆解 OAuth 2.0 的逻辑，为下一讲"基于 OAuth 真正落地 QPaint 帐号系统"打地基。
帐号（Account）
帐号 = 表征用户身份的实体，代表一个"用户"（同一自然人开多个帐号，业务上常视作不同用户）。常见表征方式：
| 表征方式 | 典型场景 |
|---|---|
| 电子邮件 | 通用 |
| 手机号 | 通用 |
| 用户自定义网络 ID | 通用 |
| 自动分配唯一 ID（UUID） | 银行卡号（不是你自己定的） |
| 身份证号（冷门） | 政府公共服务类 |
授权（Authorization）
关键判断：授权是帐号对服务的访问方式。有帐号就有授权，但二者不是一一对应——同一帐号可有多种授权。
除了上一讲提的 Token、AK/SK，还有最常见却被刻意略过的一种：用户名 + 密码（"用户名"即帐号）。为何讲网络 API 时不提它？
关键洞见：因为不安全——每次 API 请求都带密码会大大增加泄漏概率，所以要尽可能减少密码在网络中传输的次数。"用户名 + 密码"必然以最低频率使用。
它只在两类入口出现：
| 入口 | 说明 |
|---|---|
| 登录（login） | 登录那一下用用户名+密码，之后转为 Session（Cookie）授权，直到过期 |
| Token 授权的入口 | API 层 Token 授权，同样以"用户名+密码"作为获取入口之一 |
Session 授权与 Token 授权地位高度相似：
| 维度 | Session 授权（Web） | Token 授权（API 层） |
|---|---|---|
| 承载机制 | Cookie | HTTP Authorization 头 |
| 过期 | 有过期时间，可自动顺延 | 有过期时间，靠 Refresh 续 |
| 典型入口 | 登录（login） | 用户名+密码等入口 |
注意：这里的 Session 授权与"浏览器 Session"不是一回事，它登录后产生、往往有几天有效期、不随窗口关闭消失。
OAuth 2.0
QPaint 是 To C 应用，API 层自然选 Token 授权，标准是 OAuth 2.0。两类使用场景：
| 场景 | 目的 |
|---|---|
| 提供开放接口（核心场景） | 授权第三方 App 调用我的服务 |
| 作为 OpenID 提供方 | 第三方只为复用我的用户（需足够大用户基数与入口价值，如微信/QQ、支付宝、新浪微博）；为此 OpenID Foundation 引入 OpenID Connect |
OAuth 2.0 的三个角色：
| 角色 | 含义 |
|---|---|
| 服务提供商 | 含授权服务（Authorization Server）+ 资源服务（Resource Server） |
| 终端用户 / 资源拥有方（Resource Owner） | 资源存在服务商处，但归属于用户 |
| 第三方应用 / 客户端（Client） | 官方应用与第三方机制相同，故统称客户端 |
三角色交互的基本流程（A–F）：
| 步骤 | 动作 |
|---|---|
| A/B | 客户端请求授权 → 终端用户同意授权 |
| C/D | 客户端凭授权向认证服务器申请令牌 → 认证后发放令牌 |
| E/F | 客户端持令牌向资源服务器请求资源 → 校验无误开放资源 |
常见授权模式：
| 模式 | 定位 |
|---|---|
| 访问令牌（Access Token） | 最核心、请求频率最大 |
| 更新令牌（Refresh Token） | 次之，Access Token 失效后用它换新令牌 |
| 授权码（Authorization Code） | 第三方开放接口用得最多的入口 |
| 简化（Implicit）/ 用户名+密码 / 客户端模式 | 不同场景的授权入口，皆可同时换得 Access + Refresh Token |
授权码模式（Authorization Code） 流程：
| 步骤 | 动作 |
|---|---|
| A/B | 浏览器把用户重定向到认证服务 → 用户选择是否授权 |
| C | 授权后认证服务器导向网站预设的 Redirection URI，附授权码 |
| D | 网站后端持授权码 + 重定向 URI 申请令牌（对用户不可见） |
| E | 认证服务器核对授权码与重定向 URI，返回 Access + Refresh Token |
总结
本讲把帐号与授权的概念体系讲清：帐号是身份实体，授权是帐号访问服务的方式且一对多；用户名+密码因不安全只用于登录/换 Token 这类低频入口；Session 与 Token 授权地位相似，只是承载机制（Cookie vs Authorization 头）和场景（Web vs API）不同。OAuth 2.0 用三角色、A–F 流程和授权码模式，实现"不暴露用户隐私即可授权第三方"。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 帐号（Account） | 表征用户身份的实体，可用邮箱/手机/ID/UUID 等表征 |
| 授权（Authorization） | 帐号对服务的访问方式，同一帐号可多种授权 |
| Session 授权 | Web 端基于 Cookie，登录后产生、可顺延 |
| Token 授权 | API 端基于 Authorization 头，靠 Refresh 续期 |
| OAuth 2.0 / 授权码模式 | Token 授权标准；授权码模式是第三方开放接口最常用入口 |
一句话速记
帐号是"你是谁"，授权是"你能怎么访问"；密码只在登录/换 Token 时低频出现，其余靠 Session（Web）或 Token（API）；OAuth 2.0 用授权码让第三方"不碰你密码"也能拿到令牌。
几条值得记住的判断
- 同一帐号可有多种授权——帐号与授权不是一一对应。
- 密码泄漏概率随传输次数上升，所以"用户名+密码"必须最低频使用。
- Access Token 是核心、Refresh Token 续命；其余模式都只是换令牌的入口。
思考题
OAuth 授权码模式的精妙在于"第三方全程拿不到用户密码"。回到你的系统：你是否还在让第三方/内部子系统直接接触用户名密码，或把长期凭证当令牌随处传递？该如何用 Access/Refresh Token 的分层把密码的暴露面压到最小？
