Go微服务中JWT鉴权必须集中于API网关或统一中间件层，禁止各服务自行调用jwt.Parse()；否则将导致密钥泄露、校验逻辑不一致、Redis黑名单竞态等严重安全与性能问题。
直接说结论：Go微服务中用JWT做鉴权，必须配合API网关或统一中间件层，不能让每个服务自己解析jwt.Parse()；否则权限失控、登出失效、密钥泄露风险会指数级上升。
为什么不能在每个微服务里直接调用jwt.Parse()
常见错误现象是：Service-A校验完Token后放行，Service-B又重复校验一遍，看似“各自负责”，实则埋下三颗雷：
- 同一份密钥（如
[]byte("my-secret")）散落在多个服务代码里，一旦某服务被攻破，全盘沦陷； - 各服务对
exp、aud、iss字段校验逻辑不一致，比如Service-A忽略aud，Service-B强制校验，导致权限绕过； - Token吊销只能靠Redis黑名单，但每个服务都要连Redis、查黑名单、加锁——性能瓶颈和竞态条件立刻出现。
真正可行的做法是：只在网关层（如Kong、Traefik或自研Go网关）做一次jwt.Parse()，验证通过后注入X-User-ID、X-Roles等可信头，下游服务只读头、不碰Token。
github.com/golang-jwt/jwt/v5的ParseWithClaims必须传入正确KeyFunc
很多人写成固定返回密钥，比如：
立即学习“go语言免费学习笔记（深入）”；
func(token *jwt.Token) (interface{}, error) {
return []byte("secret"), nil
}
这会导致无法切换签名算法（如从HS256升级到RS256），也违背了OpenID Connect推荐的公私钥分离原则。正确做法是根据token.Header["alg"]动态返回密钥：
- 若
alg == "HS256"，返回对称密钥（仅限内部网关场景）； - 若
alg == "RS256"，从本地public.pem文件加载公钥； - 务必校验
token.Claims.(jwt.MapClaims)["iss"]是否匹配预期认证中心地址（如"https://auth.example.com"）。
漏掉iss校验，攻击者可伪造任意签发方的Token。
Token刷新机制必须区分Access Token和Refresh Token
单纯延长exp时间（比如设为7天）等于放弃主动登出能力。生产环境必须拆开两种Token：
-
Access Token生命周期短（15–60分钟），只用于API调用，网关校验后即丢弃； -
Refresh Token存于HttpOnly Cookie，带SameSite=Strict，且只允许向/auth/refresh端点提交； - 刷新时必须校验
Refresh Token的jti（唯一ID）是否在Redis黑名单中，并更新其exp和used_at时间戳。
注意：Refresh Token不能复用——每次刷新都应生成新Token并作废旧Token，否则重放攻击可无限续期。
Go中间件里提取Authorization头的边界情况要覆盖全
实际请求中Authorization头格式五花八门，光检查strings.HasPrefix(header, "Bearer ")不够：
- 可能为空格分隔不规范：
"Bearer\ttoken"或"bearer token"（大小写不敏感）； - 可能含多余空格：
"Bearer xxx"； - 可能根本没这个头，但前端误传了
X-API-Key之类替代字段（调试阶段常见）。
建议统一用正则^Bearer\s+([^\s]+)$提取，捕获组取$1，再做strings.TrimSpace()；没有Authorization头时，直接返回401 Unauthorized，不要 fallback 到其他字段。
最易被忽略的一点：JWT的iat（签发时间）必须参与校验——不是为了精度，而是防重放。网关应拒绝iat早于当前时间5秒的Token，避免NTP漂移或时钟回拨导致的校验失效。
