JWT鉴权中间件需用req.WithContext()将解析结果注入context，gRPC复用校验逻辑需提取jwt.ParseWithClaims为独立函数，权限控制应网关做粗粒度、服务内做细粒度，且必须记录审计日志。
JWT 鉴权中间件怎么写才不漏掉 http.Request 的上下文传递
直接在 http.Handler 里解析 Authorization 头并校验 JWT，但后续业务 handler 拿不到用户 ID 或角色，本质是没把解析结果塞进 context.Context。必须用 req.WithContext() 显式注入，否则下游只能重复解析或硬编码。
- 校验通过后，调用
ctx = context.WithValue(req.Context(), "user_id", userID)，注意 key 建议用自定义类型避免冲突 - 不要用字符串字面量当
context.Value的 key，例如"user_id"—— 改成type ctxKey string; const userIDKey ctxKey = "user_id" - 中间件末尾必须返回
http.HandlerFunc，且内部调用next.ServeHTTP(w, req)，不能漏掉这句，否则请求就卡住了
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 token", http.StatusUnauthorized)
return
}
tokenStr := strings.TrimPrefix(authHeader, "Bearer ")
claims := &jwt.MapClaims{}
_, err := jwt.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (interface{}, error) {
return []byte(os.Getenv("JWT_SECRET")), nil
})
if err != nil {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
ctx := context.WithValue(r.Context(), userIDKey, (*claims)["user_id"])
next.ServeHTTP(w, r.WithContext(ctx))
})
}
gRPC 服务如何复用同一套 JWT 校验逻辑
gRPC 不走 HTTP header，而是把 token 放在 metadata.MD 里，常见位置是 authorization（小写）键。不能直接复用 HTTP 中间件，但核心解析逻辑（jwt.ParseWithClaims）可以提取为独立函数。
- 在 gRPC unary interceptor 中，用
grpc.Peer().Addr或md := metadata.MD{}; md, _ = metadata.FromIncomingContext(ctx)提取 token - 校验失败时返回
status.Error(codes.Unauthenticated, "invalid token")，不是http.Error - 用户信息建议存入
context.WithValue，和 HTTP 场景保持一致，方便后续 handler 统一读取
func AuthInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
md, ok := metadata.FromIncomingContext(ctx)
if !ok {
return nil, status.Error(codes.Unauthenticated, "missing metadata")
}
tokens := md["authorization"]
if len(tokens) == 0 {
return nil, status.Error(codes.Unauthenticated, "missing token")
}
tokenStr := strings.TrimPrefix(tokens[0], "Bearer ")
claims := &jwt.MapClaims{}
_, err := jwt.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (interface{}, error) {
return []byte(os.Getenv("JWT_SECRET")), nil
})
if err != nil {
return nil, status.Error(codes.Unauthenticated, "invalid token")
}
userID := (*claims)["user_id"].(string)
newCtx := context.WithValue(ctx, userIDKey, userID)
return handler(newCtx, req)
}
为什么用 github.com/golang-jwt/jwt/v5 而不是 v4 或原生 crypto/jwt
v5 是当前维护最活跃、漏洞修复最及时的版本；v4 已被标记为 deprecated；标准库压根没有 JWT 实现，crypto/jwt 是假想包，不存在。
-
v5默认禁用unsafe模式，强制要求显式指定 signing method，避免算法混淆漏洞（如将HS256误当成none） - 签名密钥必须是
[]byte或实现func(*Token) (interface{}, error)，不能传空字符串或 nil，防止 panic - 过期时间校验默认开启（
VerifyExpiresAt），v4需手动调用token.Claims.(jwt.MapClaims).VerifyExpiresAt
权限控制该放在网关层还是微服务内部
粗粒度路由级权限（比如 “只有 admin 能访问 /admin/*”）放 API 网关；细粒度业务级权限（比如 “用户只能删自己的订单”）必须落在具体服务内部，网关无法感知业务语义。
- 网关适合做 token 解析 + 角色白名单（
roles: ["admin"]），但做不到判断order.UserID == current_user.ID - 微服务内鉴权要结合数据查询，例如先查
SELECT user_role FROM users WHERE id = ?，再比对操作所需权限 - 如果所有服务都依赖同一套 RBAC 规则，建议抽成独立的
authzgRPC 服务，避免各处硬编码权限表
别指望一个中间件解决所有问题：token 解析、身份识别、权限判定、审计日志，这四步缺一不可，而最容易被跳过的，是最后一步——没记录谁在什么时候访问了什么资源，等于没鉴权。
