架构设计分析
多点登录
单点登录
微服务接入网关实现单点登录设计思路
| 对比维度 | 方案一：网关统一认证授权（主流常用） | 方案二：网关仅转发，各服务自行处理 |
|---|---|---|
| 核心定位 | 网关充当OAuth2.0 资源服务器 | 网关只做路由转发，无认证权限逻辑 |
| 令牌校验 | 网关统一解析、校验、拦截令牌 | 下游每个微服务单独解析校验令牌 |
| 权限拦截 | 网关层统一拦截客户端接入权限 | 各资源服务自行编写权限拦截逻辑 |
| 用户信息传递 | 网关解析后明文透传用户 / 权限信息给微服务 | 下游服务自行从 Token 提取用户信息 |
| 下游服务职责 | 1. 业务接口权限二次校验2. 存入线程上下文 | 1. 自研 Token 解析逻辑2. 认证 + 权限校验 + 用户信息封装 |
| 开发成本 | 低，下游无需接入 OAuth2 机制 | 高，多服务重复编写认证授权代码 |
| 统一管控 | 权限、接入客户端全平台统一管控 | 权限分散，管控混乱，标准不统一 |
| 维护难度 | 易维护，认证逻辑集中网关 | 维护繁琐，版本不一致易出问题 |
| 适用场景 | 微服务集群、统一接口平台、多客户端接入 | 小型单体拆分、简单独立服务 |
搭建微服务授权中心
组合 1：Spring Authorization Server + Spring Security + Spring Cloud Gateway + JWT（官方主推，新项目首选）
| 组件 | 作用 |
|---|---|
| Spring Authorization Server | 授权中心（OAuth2.1/OpenID Connect） |
| Spring Security | 认证 / 授权底层、密码、会话、防护 |
| Spring Cloud Gateway | 网关统一鉴权、令牌校验、转发用户信息Spring |
| JWT（jjwt/nimbus） | 无状态令牌，网关解析后透传用户 / 权限 |
| Redis | 存储 Token、授权码、黑名单、会话 |
优点
- ✅ Spring 官方标准，持续更新，支持 OAuth2.1、OIDC
- ✅ 与 Spring Cloud 无缝集成，网关 / 服务统一安全体系Spring
- ✅ 网关统一校验 JWT，下游微服务只做业务权限Spring
- ✅ 细粒度权限 + RBAC + 方法级安全，企业级能力
- ✅ 可完全自研控制，无外部依赖，可控性强
缺点
- ❌ 配置偏多、学习曲线陡
- ❌ 需自己开发用户 / 角色 / 客户端管理界面
- ❌ 分布式会话、Token 黑名单需自己用 Redis 实现
适用：中大型微服务、Spring Cloud 体系、需要自研可控、强安全合规。
组合 2：Keycloak（独立 IAM）+ Spring Cloud Gateway + Spring Security（开箱即用，SSO 强）
| 组件 | 作用 |
|---|---|
| Keycloak | 独立授权中心 / 用户中心（OAuth2+OIDC+SAML） |
| Spring Cloud Gateway | 网关校验 Keycloak JWT、转发用户信息Spring |
| Spring Security | 微服务侧权限、RBAC、方法拦截 |
优点
- ✅ 开箱即用 IAM：用户 / 角色 / 客户端 / 权限管理 UI 全有
- ✅ 原生支持 SSO、社交登录、LDAP、MFAKeycloak
- ✅ 标准 OAuth2/OIDC，多语言 / 多端接入友好Keycloak
- ✅ 网关统一鉴权，下游服务轻量Spring
缺点
- ❌ 独立服务，运维成本高（需部署、升级、监控）
- ❌ 定制化难：UI、权限模型、登录流程改造成本高
- ❌ 对 Spring 生态友好，但非 Spring 技术栈也可用
适用：多系统统一身份、SSO 需求强、不想自研用户中心、中小团队快速落地。
组合 3：Sa-Token（国产轻量）+ Spring Cloud Gateway + Redis（极简、快速、国内流行）
| 组件 | 作用 |
|---|---|
| Sa-Token | 认证授权框架（自研 OAuth2 模式、Session/JWT） |
| Spring Cloud Gateway | 网关统一拦截、校验 Token、转发用户信息Spring |
| Redis | 分布式会话、Token 存储、续签、踢下线 |
- ✅ 极简 API、零配置起步，学习成本极低
- ✅ 内置 OAuth2 模式、SSO、JWT、RBAC、数据权限
- ✅ 国产、中文文档全、社区活跃、国内公司用得多
- ✅ 网关 + 微服务统一方案，代码量极少
缺点
- ❌ 非标准 OAuth2 实现，生态不如 Spring 官方 / Keycloak
- ❌ 企业级复杂权限模型（ABAC）支持较弱
- ❌ 多语言 / 非 Java 端接入不如标准 OIDC 友好
适用：中小型微服务、快速开发、团队 Java 栈、不想啃复杂 Spring Security。
授权中心的认证依赖：
第三方客户端的信息
微服务的信息
登录用户的信息
授权码方式
| 对比项 | 授权码模式（authorization_code） | 密码模式（password） |
|---|---|---|
| 核心流程 | 先拿授权码→后端用码换取令牌 | 直接传账号密码→直接下发令牌 |
| 安全等级 | 最高，行业标准 | 低，明文传递账号密码 |
| 交互流程 | 前端跳转授权页→用户确认授权→回调带回 code→后端静默换 token | 无页面授权，直接接口请求 |
| 令牌存放 | Token 存客户端后端，前端无感知 | 客户端可直接拿到完整令牌 |
| 适用场景 | 第三方登录、外网应用、有后端 Web 项目、主流第三方授权 | 内网系统、自研项目、自家微服务内部信任调用 |
| 优点 | 防令牌泄露、流程严谨、符合 OAuth 规范、安全性强 | 流程极简、调试方便、开发速度快 |
| 缺点 | 步骤多、配置繁琐、需配置重定向地址 | 账号密码暴露、不可对外使用、安全风险高 |
| 使用建议 | 正式生产环境首选 | 仅本地测试、内网调试使用，禁止对外暴露 |
- 开发调试、本地联调优先用密码模式，快速获取 Token
- 上线生产、对外对接必须改用授权码模式
- 网关统一鉴权场景，两种模式生成的 Token 格式一致，网关均可统一解析校验
Spring Security OAuth2 + JWT
| JWT 组成 | 说明 | 内容示例 | 编码方式 | 安全性 |
|---|---|---|---|---|
| Header（头部） | 声明令牌类型 + 签名算法 | {"alg":"HS256","typ":"JWT"} |
Base64URL | 公开可解码，不可藏敏感信息 |
| Payload（载荷） | 存放用户信息、权限、过期时间 | userId、username、roles、exp、iat | Base64URL | 明文，严禁存密码 |
| Signature（签名） | 防篡改，验证令牌合法性 | Header+Payload + 密钥 加密结果 | 加密算法生成 | 不可伪造，核心安全保障 |
| 字段名 | 全称 | 作用 |
|---|---|---|
| exp | Expiration Time | 令牌过期时间 |
| iat | Issued At | 令牌签发时间 |
| sub | Subject | 令牌面向的用户（用户 ID） |
| iss | Issuer | 令牌签发方（授权服务器） |
| jti | JWT ID | 唯一 ID，防止重放攻击 |
| aud | Audience | 令牌接收方（微服务） |
| 对比项 | 对称加密（HS256） | 非对称加密（RSA） |
|---|---|---|
| 密钥 | 只有1 个密钥（签名密钥） | 公钥 + 私钥一对 |
| 签名 | 私钥签名 + 私钥验证 | 私钥签名 + 公钥验证 |
| 安全性 | 一般，密钥泄露即伪造令牌 | 极高，公钥公开也无法伪造 |
| 网关 / 微服务 | 所有服务必须持有 same 密钥 | 仅授权服务器持私钥，其他用公钥 |
| 配置难度 | 简单，一行代码 | 稍复杂，需要生成 jks 证书 |
| 生产推荐 | 不推荐 | 强烈推荐 |
授权服务器用【私钥】给 JWT 签名 → 网关 / 微服务用【公钥】验证签名是否合法公钥可以随便公开，私钥必须死死保住。
颁发 Token（授权服务器）
- 用户登录成功
- 生成 JWT 的头部、载荷
- 用私钥对头部 + 载荷进行签名
- 返回 JWT 令牌给客户端
→ 只有授权服务器能签发合法 Token
- 前端把 JWT 传到网关
- 网关用公钥验证签名
- 验证通过 → 令牌没被篡改、是合法签发
- 放行请求，转发用户信息给微服务
→ 公钥只能验证，不能伪造令牌