JWT鉴权核心是每次请求校验签名、有效期及自定义声明;解析需显式启用jwt.WithExpirationRequired()等选项,middleware中须严格校验Bearer头并安全注入claims。

JWT鉴权的核心判断:它不是“登录即发token”,而是“每次请求都校验签名+有效期+自定义声明”
Go Web 里用 JWT,最容易错的地方是把 jwt.Parse 当成万能解码器——它只做解析和基础校验,不自动检查 exp、不验证 iss、也不拦截已注销的 token。真正起作用的是你手动调用 token.Valid 后的一系列判断逻辑。
用 github.com/golang-jwt/jwt/v5 解析并校验 token 的标准写法
注意 v4 升级到 v5 后,Parse 方法签名变了,且默认不再自动校验 exp 和 nbf。必须显式传入 jwt.WithValidMethods 和 jwt.WithExpirationRequired() 等选项。
func parseToken(tokenString string) (*jwt.Token, error) {
keyFunc := func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return []byte("your-secret-key"), nil
}
token, err := jwt.Parse(tokenString, keyFunc,
jwt.WithValidMethods([]string{"HS256"}),
jwt.WithExpirationRequired(),
jwt.WithIssuedAt(),
)
if err != nil {
return nil, err
}
if !token.Valid {
return nil, errors.New("token is invalid")
}
return token, nil
}
-
jwt.WithExpirationRequired()是关键:没有它,过期的 token 仍会返回token.Valid == true -
keyFunc必须返回interface{},不能直接返回[]byte(v5 要求更严格) - 如果用了 RSA,
keyFunc应返回*rsa.PublicKey,且需提前加载 PEM 文件
在 HTTP middleware 中提取并验证 token 的常见陷阱
很多人直接从 r.Header.Get("Authorization") 取值,但漏掉前缀校验或空值处理,导致 panic 或静默失败。
- Authorization header 格式必须是
"Bearer xxx",要切分并校验前缀 - token 字符串可能含空格、换行或 URL 编码,需先
strings.TrimSpace - 不要在 middleware 里直接
http.Error,应统一返回http.StatusUnauthorized并提前return - 解析失败时,别返回详细错误(如 “token expired”),避免泄露信息;统一返回
401 Unauthorized
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
authHeader := r.Header.Get("Authorization")
if authHeader == "" {
http.Error(w, "missing Authorization header", http.StatusUnauthorized)
return
}
parts := strings.Split(authHeader, " ")
if len(parts) != 2 || parts[0] != "Bearer" {
http.Error(w, "invalid Authorization format", http.StatusUnauthorized)
return
}
token, err := parseToken(parts[1])
if err != nil {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
// 把 user ID 或 claims 注入 context,供后续 handler 使用
ctx := context.WithValue(r.Context(), "user_id", token.Claims.(jwt.MapClaims)["user_id"])
next.ServeHTTP(w, r.WithContext(ctx))
})
}
如何安全地刷新 token 而不暴露 refresh token 泄露风险
JWT 本身不可撤销,所以 refresh token 必须单独存储、限制使用次数、绑定设备指纹,并走独立 endpoint。
立即学习“go语言免费学习笔记(深入)”;
- refresh token 不该和 access token 用同一密钥签名,建议用不同 secret 或 RSA 私钥
- refresh endpoint 必须要求原始 access token(用于校验当前会话有效性),再核对 DB 中的 refresh token 是否未失效、未被使用过
- 每次成功刷新后,旧 refresh token 必须立即失效(DB 标记为 used/expired)
- 不要把 refresh token 放在 localStorage —— 推荐用 httpOnly + Secure Cookie 存储
复杂点在于:access token 过期时间短(如 15 分钟),refresh token 过期时间长(如 7 天),但它的生命周期必须可主动终止。这需要服务端维护一个极简的 refresh token 白名单或黑名单(比如 Redis 中存 refresh_token → user_id + expires_at)。










