jwt签发必须由统一认证服务完成，各微服务仅用公钥验签且不接触私钥；服务间调用应换签短期jwt，登出与刷新需依赖redis等外部存储实现状态管理。
JWT 签发必须由统一认证服务（Auth Service）完成
微服务架构中，jwt 不能由各服务自行签发，否则密钥分散、过期策略不一致、无法统一吊销。所有登录请求必须路由到独立的 auth-service，它负责验证凭证、生成 jwt 并返回给客户端。
常见错误是让订单服务或用户服务自己调用 jwt.Sign() —— 这会导致：exp 时间不统一、iss 字段混乱、无法做黑名单校验。
-
auth-service应使用私钥（如RSA256）签名，公钥分发给其他服务用于验签 - 签发时必须设置
iss（固定为"auth-service"）、aud（可选，如["order", "user"]）、nbf和exp - 返回给前端的
access_token不应包含敏感字段（如密码哈希、数据库 ID），只放sub（用户 ID）、role、perms等授权所需信息
其他服务用公钥验签，不接触私钥
订单服务、用户服务等业务服务只做 JWT 验证，不参与签发。它们从配置或远程服务（如 Consul、etcd）加载 auth-service 提供的 PEM 格式公钥，用 github.com/golang-jwt/jwt/v5 验证签名和标准声明。
容易踩的坑是：把私钥硬编码进业务服务，或用对称算法（HS256）—— 一旦某个服务被攻破，整个认证体系即失效。
立即学习“go语言免费学习笔记（深入）”；
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
- 验签时必须显式校验
Valid()，且检查err == nil，不能只看token.Valid字段 - 务必启用
VerifyAudience和VerifyIssuer，避免 token 被滥用于非目标服务 - 建议在中间件中统一解析
Authorization: Bearer <token></token>，提取claims后注入context.Context，供 handler 使用
func jwtMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
auth := r.Header.Get("Authorization")
if !strings.HasPrefix(auth, "Bearer ") {
http.Error(w, "missing token", http.StatusUnauthorized)
return
}
tokenStr := strings.TrimPrefix(auth, "Bearer ")
token, err := jwt.Parse(tokenStr, func(token *jwt.Token) (interface{}, error) {
if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
}
return publicKey, nil // publicKey 是 *rsa.PublicKey
})
if err != nil || !token.Valid {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
claims, ok := token.Claims.(jwt.MapClaims)
if !ok {
http.Error(w, "invalid claims", http.StatusUnauthorized)
return
}
ctx := context.WithValue(r.Context(), "user_id", claims["sub"])
next.ServeHTTP(w, r.WithContext(ctx))
})
}
服务间调用需透传或重签短期 JWT
当订单服务需要调用库存服务时，不能直接复用客户端传来的原始 access_token（可能已快过期、aud 不匹配）。更安全的做法是：订单服务用自己的服务身份（如 service-account）向 auth-service 换取一个新 token，aud 设为 "inventory"，exp 缩短至 5–10 分钟。
另一种轻量方式是透传原始 token，但要求所有服务都信任同一 iss 且 aud 为空或宽泛（如 ["*"]）—— 这会削弱边界控制，仅适用于内网可信环境。
- 服务账户（
client_id/client_secret）应通过 Vault 或 Kubernetes Secret 注入，不可写死 - 换 token 接口建议走内部 gRPC（如
auth-service.Auth/ExchangeToken），避免暴露在公网 - 若用 HTTP 调用，务必加 mTLS 双向认证，防止 token 泄露
刷新机制与登出需依赖外部状态存储
JWT 默认无状态，所以无法单点登出或主动失效。要支持刷新和登出，必须引入外部存储（如 Redis）记录活跃 token 的 jti 或绑定设备指纹。
别指望靠缩短 exp 解决一切问题 —— 长期有效的 refresh token 仍需管理生命周期。
-
auth-service在签发access_token时必须生成唯一jti，并存入 Redis，设置 TTL 略长于access_token有效期 - 登出接口不是“删 token”，而是将该
jti加入 Redis 黑名单（SET jti:xxx 1 EX 86400），验签中间件需同步查表 - refresh endpoint 必须校验原
refresh_token的jti是否未被使用过，且只允许单次使用（用后即焚）
