3.1 登录并取得 JWT#

3.2 携带 JWT 访问受保护接口#

登录接口本身必须先放行，否则用户会陷入“没有 token 就不能登录，没有登录又拿不到 token”的死循环。除此以外的 APP 请求统一经过鉴权。

5.1 外部路径与服务内路径#

外部路径多出的 /user 是 Gateway 路由前缀。StripPrefix=1 会在转发前移除这一段，所以 Controller 只需要声明 /api/v1/login/login_auth。

5.2 三种业务分支#

先写清楚输入真值表，Service 才不容易把错误请求误当成游客：

游客登录不是“任意一项为空”，而是“两项同时为空”。代码中分别使用 && 和 ||，正是为了表达这两个不同条件。

9.1 当前项目的计算过程#

注册或初始化用户数据时，数据库保存的是：

1
password_digest = MD5(明文密码 + salt)

登录时执行同样的计算：

1
用户输入密码
2
    + 数据库中的 salt
3
    ↓
4
DigestUtils.md5DigestAsHex(...)
5
    ↓
6
与数据库 password 字段比较

盐值的作用是让相同明文密码产生不同摘要，降低通用彩虹表直接命中的风险。盐值不需要像密码一样保密，但每个用户都应该使用独立、随机的盐。

拼接顺序必须与生成数据库密码时一致。数据库若保存的是 MD5(password + salt)，登录却计算 MD5(salt + password)，结果一定不同。

9.2 为什么返回前还要清除密码和盐#

即使数据库保存的是摘要，也不能把它返回客户端。攻击者取得摘要后仍可以离线猜测密码；盐值一并泄漏会让猜测过程更直接。因此响应中只保留客户端真正需要的用户资料。

9.3 生产系统为什么不应继续使用 MD5#

MD5 的主要问题不是“有没有加盐”，而是它计算太快。攻击者可以用 GPU 高速尝试大量候选密码。生产环境应优先使用专门为密码设计的慢哈希算法，例如：

• BCrypt；
• Argon2id；
• PBKDF2。

同时还要配合：

• HTTPS，避免明文凭据在网络中传输；
• 登录失败限流与风控，抑制暴力破解；
• 每个用户独立随机盐；
• 不在日志中输出密码、摘要或完整 token；
• 使用明确字符集，例如 UTF-8，避免 getBytes() 随运行环境变化；
• 对锁定账号、注销账号增加状态检查；
• 对“用户不存在”和“密码错误”谨慎设计外部提示，避免账号枚举。

所以，加盐 MD5 在本文中是“理解现有课程代码”，不是生产安全方案推荐。

10.1 JWT 中保存什么#

当前工具类会写入以下信息：

下面保留了真实构造流程，但签名材料只使用配置占位符，不能把真实密钥、完整 token 或本机配置写入文章：

1
private static final int TOKEN_TIME_OUT = 3_600;
2

3
public static String getToken(Long id) {
4
    Map<String, Object> claims = new HashMap<>();
5
    claims.put("id", id);
6

7
    long currentTime = System.currentTimeMillis();
8

9
    return Jwts.builder()
10
            .setId(UUID.randomUUID().toString())
11
            .setIssuedAt(new Date(currentTime))
12
            .setSubject("system")
13
            .setIssuer("heima")
14
            .setAudience("app")
15
            .compressWith(CompressionCodecs.GZIP)
16
            .signWith(SignatureAlgorithm.HS512, loadSigningKeyFromSecureConfig())
17
            .setExpiration(new Date(currentTime + TOKEN_TIME_OUT * 1000L))
18
            .addClaims(claims)
19
            .compact();
20
}

loadSigningKeyFromSecureConfig() 是脱敏表达，重点是“签发端和验签端必须取得兼容的签名密钥”，而不是把密钥硬编码在教程里。

10.2 JWT 是签名，不是加密#

JWT 的 Payload 通常可以被客户端解码。签名保证的是“内容没有被篡改，并且来自持有密钥的一方”，不代表 Payload 对客户端不可见。

因此 JWT 中适合放用户 ID、角色标识等最小身份信息，不适合放密码、手机号、密钥或其他敏感资料。

10.3 签发端与验签端必须一致#

当前项目在公共 utils 和 APP Gateway 中各有一份 AppJwtUtil。两份工具必须在以下方面保持一致：

• 签名算法；
• 签名密钥；
• Claims 名称，例如都使用 id；
• 过期时间和校验语义。

重复工具类容易出现一边改了、另一边没改的维护风险。课程阶段可以先跑通链路，后续可以把认证配置集中管理，或抽成双方共同依赖的安全组件。

11.1 Gateway 连接 Nacos#

仓库中的 bootstrap.yml 负责声明 Gateway 的端口、应用名和 Nacos 入口。公开文章应使用环境变量或占位地址：

1
server:
2
  port: 51601
3

4
spring:
5
  application:
6
    name: leadnews-app-gateway
7
  cloud:
8
    nacos:
9
      discovery:
10
        server-addr: ${NACOS_ADDR}
11
      config:
12
        server-addr: ${NACOS_ADDR}
13
        file-extension: yml

discovery 用于服务发现，config 用于读取配置中心内容。课程环境中的真实 Nacos 地址不应写进博客。

11.2 在 Nacos 中配置用户服务路由#

下面是课程环境可使用的路由示例：

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
        - id: user
6
          uri: lb://leadnews-user
7
          predicates:
8
            - Path=/user/**
9
          filters:
10
            - StripPrefix=1

逐项理解：

• id: user：路由的唯一名称。
• lb://leadnews-user：通过注册中心按服务名负载均衡，而不是写死某个实例地址。
• Path=/user/**：只有带 /user/ 前缀的请求进入这条路由。
• StripPrefix=1：转发前删除第一段 /user。

路径变化如下：

1
客户端请求：
2
/user/api/v1/login/login_auth
3

4
Gateway 删除一段前缀后：
5
/api/v1/login/login_auth
6

7
Controller 匹配：
8
@RequestMapping("/api/v1/login")
9
@PostMapping("/login_auth")

如果客户端直接访问 Gateway 的 /api/v1/login/login_auth，它不会命中 Path=/user/**；如果忘记 StripPrefix=1，用户服务收到的路径仍带 /user，也会因匹配不到 Controller 而返回 404。

12.1 为什么白名单使用精确路径#

如果写成：

1
request.getURI().getPath().contains("/login")

那么任何路径中只要出现 /login 都可能绕过鉴权。路径命名不是权限规则，公开接口应该以明确、可审查的白名单管理。

当前过滤器看到的是 Gateway 入口路径，所以常量包含 /user。Controller 看到的是路由过滤器移除前缀后的路径，两者不要混淆。

12.2 为什么失败直接返回 HTTP 401#

response.setComplete() 会结束响应式链路，不再访问下游服务。这里返回的是 HTTP 层未认证，而不是用户服务返回的业务 JSON 错误：

• 登录凭据不完整：请求已经到达用户服务，通常是 HTTP 200 + 业务错误码。
• token 缺失或无效：请求在 Gateway 被拒绝，返回 HTTP 401。

客户端必须同时判断 HTTP 状态码和响应体中的业务码。

12.3 为什么必须覆盖 userId#

客户端可以随意伪造请求头：

1
userId: 999999

如果 Gateway 使用客户端值，下游就可能把攻击者当成其他用户。正确做法是：

1. 先验证 JWT。
2. 从可信 Claims 读取 id。
3. 使用 headers.set 覆盖同名头，而不是 add 一个并存值。
4. 把真正构造出的 mutatedExchange 传给过滤器链。

这一步把“JWT 已验签”真正转化成“下游可以使用的可信身份上下文”。

12.4 当前过期校验的语义#

JWT 解析器在解析签名时会处理 exp；过期 token 会被转换为不可用 Claims。当前 verifyToken 还根据剩余时间返回状态：

• 1：Claims 为空或已过期；
• 2：校验异常；
• -1 或 0：过滤器继续放行，其中 0 表示临近刷新窗口。

目前过滤器没有真正签发刷新 token，所以“接近过期”仍只是放行。生产系统需要明确设计续期方案，而不能仅有一个状态码。

13.1 游客登录#

请求：

1
POST http://localhost:51601/user/api/v1/login/login_auth HTTP/1.1
2
Content-Type: application/json
3

4
{
5
  "phone": "",
6
  "password": ""
7
}

期望响应结构：

1
{
2
  "code": 200,
3
  "errorMessage": "操作成功",
4
  "data": {
5
    "token": "<JWT 已省略>"
6
  }
7
}

游客 token 的 id 为 0。这只表示允许游客访问开放给游客的受保护资源，不等于游客拥有普通用户的全部权限；下游服务仍需要根据业务操作判断授权。

13.2 凭据只填写一项#

请求：

1
POST http://localhost:51601/user/api/v1/login/login_auth HTTP/1.1
2
Content-Type: application/json
3

4
{
5
  "phone": "<测试手机号>",
6
  "password": ""
7
}

期望响应结构：

1
{
2
  "code": 501,
3
  "errorMessage": "手机号和密码必须同时填写"
4
}

注意 HTTP 请求可能仍然成功到达用户服务，因此 HTTP 状态可能是 200；真正的失败原因在业务 code 中。

13.3 正常账号登录#

请求：

1
POST http://localhost:51601/user/api/v1/login/login_auth HTTP/1.1
2
Content-Type: application/json
3

4
{
5
  "phone": "<测试手机号>",
6
  "password": "<测试密码>"
7
}

期望响应结构：

1
{
2
  "code": 200,
3
  "errorMessage": "操作成功",
4
  "data": {
5
    "token": "<JWT 已省略>",
6
    "user": {
7
      "id": 10001,
8
      "name": "<测试用户>",
9
      "phone": "<脱敏手机号>"
10
    }
11
  }
12
}

示例中的手机号是为了公开展示而脱敏的。当前代码只清除了 password 和 salt，phone 等其他实体字段仍会按数据库值序列化；是否向客户端返回完整手机号应根据真实产品契约决定，生产实现更适合使用响应 VO 明确控制字段。无论采用哪种契约，响应中都不应出现 password 和 salt。

13.4 不带 token 访问受保护接口#

请求：

1
POST http://localhost:51601/article/api/v1/article/load HTTP/1.1
2
Content-Type: application/json
3

4
{}

期望结果：

1
HTTP/1.1 401 Unauthorized

13.5 携带合法 token#

1
POST http://localhost:51601/article/api/v1/article/load HTTP/1.1
2
Content-Type: application/json
3
token: <刚刚获得的完整 JWT>
4

5
{}

合法 JWT 应被放行；把 token 任意改动一个字符后再次请求，应返回 HTTP 401。

16.1 请完整讲一下 APP 登录与鉴权流程#

参考回答：

客户端先请求 APP Gateway 的登录路径，Gateway 对精确登录白名单直接放行，并通过 Nacos 路由到用户服务。Controller 把 JSON 转成 LoginDto 后交给 Service。Service 区分游客、不完整参数和正常登录；正常登录按手机号查询 ap_user，用数据库盐值计算密码摘要并比对，成功后把用户 ID 写入 JWT。后续请求携带 token 经过 Gateway，全局过滤器完成验签和过期判断，从 Claims 取出用户 ID，覆盖客户端可能伪造的 userId 请求头，再转发给下游服务。

常见追问：为什么不让每个微服务自己验 token？

统一在 Gateway 做基础认证能减少重复代码并保持入口规则一致；下游仍要负责具体业务授权，不能把“已登录”误当成“有权执行所有操作”。

16.2 为什么游客登录和参数不完整必须分开#

参考回答：

游客登录是手机号和密码同时为空，参数不完整是只有一项为空。前者使用 &&，后者使用 ||。如果把“任意一项为空”都当成游客，用户输错或漏填密码时也会获得游客 token，接口语义会变得模糊。

常见追问：怎样防止这类组合条件出错？

先写四行真值表，再为全空、全有、只缺手机号、只缺密码分别写测试。

16.3 为什么 Controller 不直接查询数据库和校验密码#

参考回答：

Controller 负责 HTTP 协议适配，Service 负责登录业务，Mapper 负责数据访问。把密码校验放在 Service 后，规则可以被其他入口复用，也更容易单独测试；Controller 不会随着业务分支增加而失控。

常见追问：DTO、Entity、VO 分别负责什么？

DTO 承载请求输入，Entity 映射数据库表，VO 定义允许返回给客户端的字段。生产项目不建议直接返回 Entity。

16.4 加盐 MD5 比明文好在哪里，为什么生产仍不推荐#

参考回答：

加盐后，相同密码不会得到完全相同的摘要，能降低通用彩虹表攻击效果，也避免直接存储明文。但 MD5 计算速度太快，攻击者仍可高速暴力枚举。生产应该使用 BCrypt、Argon2id 或 PBKDF2，并配合独立随机盐、HTTPS、限流和安全日志。

常见追问：盐值需要加密保存吗？

盐值通常可以与摘要一起保存，关键是每个用户独立随机；真正不能泄漏的是密码、完整凭据和服务端密钥。

16.5 JWT 和传统 Session 有什么区别#

参考回答：

Session 通常把登录状态保存在服务端，客户端只持有会话标识；JWT 把最小 Claims 放在签名 token 中，服务端可以无会话地验证，适合微服务横向扩展。但 JWT 主动失效更困难、Payload 可见、token 泄漏后在过期前可能被利用，因此要控制有效期并设计撤销或刷新机制。

常见追问：JWT 是不是绝对无状态？

只有完全不做撤销、黑名单和服务端会话时才接近无状态；一旦需要强制下线或刷新 token，通常仍会引入一定服务端状态。

16.6 JWT 签名和加密有什么区别#

参考回答：

签名用于验证来源和完整性，不能保证 Payload 保密；加密才用于隐藏内容。普通签名 JWT 可以被解码，所以只放最小身份信息，不能放密码、手机号或密钥。

常见追问：为什么篡改一个字符会失败？

Payload 或 Header 变化后，原签名与新内容不匹配，Gateway 使用服务端密钥验签时会拒绝。

16.7 为什么登录白名单不能使用 contains("/login")#

参考回答：

contains 把路径命名当成权限规则，可能意外放行任何带 /login 的接口。鉴权白名单应该使用明确路径或经过审查的路由匹配规则，默认拒绝未登记的公开接口。

常见追问：精确字符串就一定没有问题吗？

还要统一处理尾斜杠、路径规范化、上下文路径和新增公开接口；项目变大后可使用集中配置的白名单并配套测试。

16.8 为什么 Gateway 要覆盖 userId，而不是直接相信请求头#

参考回答：

客户端请求头属于不可信输入，攻击者可以随意伪造。Gateway 先验签，再从 Claims 取 id，使用 set 覆盖同名头，才能让下游拿到可信身份。使用 add 可能留下多个值，业务端取哪个值会产生歧义。

常见追问：下游拿到 userId 后还要做什么？

还要做资源级授权，例如只能修改自己的资料。认证确认“你是谁”，授权判断“你能做什么”。

16.9 Nacos 路由中的 lb:// 和 StripPrefix=1 有什么作用#

参考回答：

lb://leadnews-user 表示从 Nacos 按服务名选择用户服务实例，实现服务发现和负载均衡；StripPrefix=1 会删除外部路径第一段 /user，让剩余路径匹配用户服务 Controller。

常见追问：忘记去前缀通常是什么现象？

Gateway 能找到服务，但用户服务收到 /user/api/...，与 Controller 的 /api/... 不匹配，通常返回 404。

16.10 HTTP 401 和业务错误码有什么区别#

参考回答：

token 缺失、过期或无效时，请求在 Gateway 被拒绝，适合返回 HTTP 401。手机号缺失、用户不存在、密码错误等请求已经进入用户服务，当前项目通过 ResponseResult 返回业务码。客户端要先判断 HTTP 状态，再解析业务码。

常见追问：401 和 403 又有什么区别？

401 表示尚未通过身份认证；403 表示身份已经确认，但没有执行当前操作的权限。

16.11 JWT 过期与刷新应该怎样设计#

参考回答：

当前 token 带 exp，Gateway 解析时会拒绝过期 token；临近过期状态目前没有真正刷新。完整方案通常使用短期 access token 和更严格保存的 refresh token，刷新时校验会话状态，并支持撤销、轮换和异常检测。

常见追问：为什么不把 access token 设置得特别长？

有效期越长，token 泄漏后的可利用窗口越大。有效期需要在安全性和用户体验之间权衡。

16.12 当前实现还可以怎样演进#

参考回答：

我会优先把 MD5 升级为 BCrypt 或 Argon2id，用登录响应 VO 替代直接返回 Entity，补账号状态检查和登录限流；再统一签发端、验签端的 JWT 配置，改用标准 Authorization: Bearer，并补充真实账号、过期、刷新、身份头覆盖和权限校验的自动化测试。

常见追问：为什么不是先做复杂的统一认证中心？

演进应先解决当前明确的安全和一致性问题。课程项目规模较小时，先把边界、配置和测试做稳，再根据多端登录、单点登录等真实需求决定是否引入认证中心。