推荐采用mTLS+JWT混合方案：用mTLS保障传输安全，JWT由统一授权中心签发并用RS256签名，服务启动时加载公钥，校验时严格匹配iss、aud、exp，并通过X-Service-Token传递，gRPC场景使用PerRPCCredentials透传。
用 JWT 实现服务间双向认证（mTLS + JWT 混合）
单纯靠 JWT 做服务间鉴权不安全，必须配合传输层加密。Golang 微服务间通信推荐 mTLS（双向 TLS）兜底传输安全，再叠加 JWT 做服务身份断言。关键不是“要不要 JWT”，而是“JWT 由谁签发、怎么校验、何时刷新”。
-
issuer必须是统一的内部授权中心（如自建authz-svc），所有服务只信任该 issuer 的公钥 - 服务启动时通过环境变量或配置中心加载
issuer public key（PEM 格式），避免硬编码或每次远程拉取 - JWT 的
aud字段必须显式设为被调用服务名（如"user-service"），校验时严格比对，防止 token 被跨服务复用 - 不要用
HS256；一律用RS256或ES256，私钥仅存于授权中心，服务端只持公钥
在 Gin / Echo 中拦截并校验 service-to-service JWT
HTTP 中间件需区分「外部请求」和「内部服务请求」。不能把面向用户的 JWT 校验逻辑直接套用到服务间调用上——它们的签发源、有效期、scope 都不同。
- 建议在请求头中约定专用字段，如
X-Service-Token，而非复用Authorization: Bearer xxx - 校验前先检查
req.TLS != nil && len(req.TLS.PeerCertificates) > 0，确保 mTLS 已建立，否则直接拒绝 - 使用
github.com/golang-jwt/jwt/v5，注意ParseWithClaims必须传入自定义jwt.MapClaims并手动验证iss、aud、exp - 失败时返回
401 Unauthorized，且响应体不要暴露细节（如不说明是 exp 过期还是 aud 不匹配）
func ServiceAuthMiddleware(pubKey *rsa.PublicKey) gin.HandlerFunc {
return func(c *gin.Context) {
tokenStr := c.GetHeader("X-Service-Token")
if tokenStr == "" {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
token, err := jwt.ParseWithClaims(tokenStr, &jwt.MapClaims{}, func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodRSA); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return pubKey, nil
})
if err != nil || !token.Valid {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
claims, ok := token.Claims.(jwt.MapClaims)
if !ok || claims["iss"] != "https://authz.internal" || claims["aud"] != "order-service" {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
c.Next()
}
}
gRPC 场景下用 per-RPC credentials 透传服务身份
gRPC 没有 HTTP 头概念，服务间认证必须走 credentials.PerRPCCredentials 接口。别试图在 UnaryInterceptor 里解析 metadata 手动校验——那会绕过 transport 安全边界。
- 客户端实现
GetRequestMetadata，从本地缓存读取有效期内的 JWT（避免每次调用都生成新 token） - 服务端用
grpc.Creds(credentials.NewTLS(...))强制启用 mTLS，再在 interceptor 中提取metadata.MD并校验X-Service-Token对应的 JWT - JWT 过期时间建议设为 5–15 分钟，配合后台 goroutine 定期刷新（如提前 30 秒发起 renew 请求）
- 不要把 service name 写死在 token payload 里；应由授权中心根据 client cert 的
Subject.CommonName动态签发，防伪造
权限决策不该放在网关，而应在业务服务自身
API 网关（如 Kong、Traefik）适合做流量路由和基础鉴权（如 API Key），但服务间细粒度权限（如 “order-service 是否允许调用 inventory-service 的 /v1/stock/deduct”）必须由被调用方自己判断。
立即学习“go语言免费学习笔记（深入）”；
- 每个服务应维护一份
service-policy.json或从配置中心拉取 RBAC 规则，规则粒度到service:action（如"payment-service:charge"） - 校验 JWT 后，提取
sub（调用方服务名）和scope（声明的能力列表），查表比对当前接口是否在允许范围内 - 避免在每次 RPC 中远程查询权限中心——延迟高、单点故障风险大；可定期拉取规则快照 + 本地 LRU cache
- 错误日志中记录
sub、aud、requested path即可，不记录完整 token，防止密钥泄露
