17370845950

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.Statu
sUnauthorized)
            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 规则，建议抽成独立的 authz gRPC 服务，避免各处硬编码权限表

别指望一个中间件解决所有问题：token 解析、身份识别、权限判定、审计日志，这四步缺一不可，而最容易被跳过的，是最后一步——没记录谁在什么时候访问了什么资源，等于没鉴权。