很多人存在一个常见误区，认为 JWT 和 OAuth2 是竞争关系。事实上，两者并非对立，而是互补关系：OAuth2 负责授权流程，JWT 则作为令牌格式，用于在授权后传递身份信息。
一、鉴权认证技术选型与作用场景
| 技术 | 核心定位 | 解决的问题 | 典型场景 | 选型建议 |
|---|---|---|---|---|
| JWT | 令牌格式 / 无状态凭证 | 如何在服务间安全传递用户身份，且服务端无需存储 Session | 前后端分离、微服务间传递用户身份、API 网关鉴权 | 微服务标配，但需配合黑名单/短期过期解决注销问题 |
| OAuth2 | 授权协议 | 如何让第三方应用在不获取用户密码的前提下访问用户资源 | 第三方登录（微信/QQ/GitHub）、开放平台 API 授权 | 涉及第三方授权时必选，单纯内部系统不必引入 |
| OIDC | 身份认证协议 | OAuth2 只授权不认证，如何获取用户身份信息 | 用户登录、SSO 单点登录、获取用户 Profile | 需要“登录”功能时，OIDC 是 OAuth2 的标准补充 |
| RBAC | 权限模型 | 如何按“角色”批量分配权限，避免逐个用户配置 | 后台管理系统、企业内部系统、SaaS 多租户 | 权限模型的基础，80% 场景够用 |
| ABAC | 权限模型 | RBAC 角色爆炸，如何按“属性”动态授权 | 数据权限（本部门/本人）、动态规则（时间/地点/IP） | RBAC 不够用时升级，适合复杂数据权限场景 |
| ReBAC | 权限模型 | 如何表达“谁拥有什么”“谁和谁有关”的关系型权限 | 云盘、文档协作、社交关系、组织架构继承 | 关系型权限场景，可参考 Google Zanzibar 模型 |
| mTLS | 网络层身份认证 | 服务间通信如何互相验证身份，防止中间人攻击 | K8s + Istio 服务网格、零信任架构、金融级内网 | 服务网格标配，替代 JWT 在服务间的传递 |
| Private Key JWT | 客户端强认证 | Client Secret 太弱，如何更强地验证客户端身份 | 高安全场景的 OAuth2 客户端认证 | 替代简单 Secret，适合金融、医疗等高安全要求 |
| SSO | 单点登录方案 | 多个系统如何一次登录、处处通行 | 企业内部多系统、SaaS 多产品线 | 基于 OIDC/CAS 实现，减少重复登录 |
| CAS | 单点登录协议 | 老牌 SSO 协议，如何集中管理登录 | 高校、传统企业内网 | 老项目常见，新项目优先 OIDC |
二、按场景选型决策表
| 业务场景 | 推荐组合 | 理由 |
|---|---|---|
| 后台管理系统（内部） | JWT + RBAC | 用户量小，角色固定，RBAC 足够 |
| SaaS 多租户系统 | OAuth2 + OIDC + RBAC + ABAC | 需要第三方登录 + 多租户数据隔离 + 精细权限 |
| 开放平台（第三方接入） | OAuth2 + OIDC + JWT | 第三方授权 + 用户身份 + 令牌传递 |
| 微服务内部调用 | JWT + mTLS | JWT 传用户身份，mTLS 保证服务间通信安全 |
| K8s + Istio 服务网格 | mTLS + JWT | mTLS 做服务间身份，JWT 做用户级鉴权 |
| 数据权限（本部门/本人） | RBAC + ABAC | 角色控制功能权限，属性控制数据权限 |
| 文档协作 / 云盘 | ReBAC | 权限继承自文件夹/组织关系 |
| 企业 SSO 单点登录 | OIDC + SSO | 一次登录，多系统通行 |
| 金融核心系统 | OAuth2 + OIDC + mTLS + Private Key JWT | 高安全要求，多层防护 |
| 小程序 / App 登录 | OAuth2 + OIDC + JWT | 微信/手机号登录 + 令牌传递 |
三、鉴权认证分层架构（文字版）
text
┌─────────────────────────────────────────────────────────────┐
│ 用户层（User） │
│ 用户登录 → OIDC（认证）→ 获取 id_token + access_token │
├─────────────────────────────────────────────────────────────┤
│ 网关层（Gateway） │
│ API 网关 → JWT 校验 → 解析用户身份 → 转发请求 │
│ → OAuth2 校验（第三方授权场景） │
├─────────────────────────────────────────────────────────────┤
│ 服务层（Service） │
│ 服务间调用 → mTLS（服务身份） + JWT（用户身份） │
│ 业务鉴权 → RBAC（功能权限） + ABAC（数据权限） + ReBAC（关系） │
├─────────────────────────────────────────────────────────────┤
│ 数据层（Data） │
│ 数据行级权限 → ABAC（属性过滤） / ReBAC（关系过滤） │
└─────────────────────────────────────────────────────────────┘
四、各技术核心作用一句话总结
| 技术 | 一句话作用 |
|---|---|
| JWT | 无状态令牌，服务间传递用户身份 |
| OAuth2 | 第三方授权，不暴露密码即可访问资源 |
| OIDC | 基于 OAuth2 的身份认证，用于登录 |
| RBAC | 按角色分配权限，权限模型基础 |
| ABAC | 按属性动态授权，解决数据权限 |
| ReBAC | 按关系授权，解决权限继承 |
| mTLS | 服务间双向证书认证，零信任基础 |
| Private Key JWT | 客户端强认证，替代 Client Secret |
| SSO | 一次登录，多系统通行 |
| CAS | 老牌 SSO 协议，传统企业常用 |
五、选型核心原则
-
认证与授权分离：OAuth2 管授权，OIDC 管认证，JWT 管传递。
-
权限模型分层：RBAC 打底，ABAC 补数据权限，ReBAC 补关系权限。
-
网络层与服务层分离：mTLS 管服务间身份，JWT 管用户身份。
-
按需引入：内部系统 JWT + RBAC 足够，不必上 OAuth2 + OIDC + ABAC 全家桶。
-
安全等级匹配：金融级加 mTLS + Private Key JWT，普通业务 JWT + RBAC 即可。
