Golang中实现RPC认证需结合TLS加密与JWT校验：TLS保障通信安全，JWT验证身份权限；服务端用credentials.NewTLSFromFile加载证书，客户端配置根证书；通过gRPC metadata在authorization头透传JWT，并用UnaryInterceptor统一校验；可选mTLS双向认证增强信任，Token应短时效并配合刷新机制。
使用 Golang 实现 RPC 认证，核心是把 TLS 加密通道和 JWT 身份校验结合起来：TLS 保证通信不被窃听或篡改，JWT 保证调用方身份可信且权限可验。关键不在“能不能做”，而在“怎么让两者自然协作”——服务端用 TLS 握手确认客户端证书（可选），再在 RPC 方法入口解析并验证 JWT；客户端则在发起调用前生成合法 Token，并通过 TLS 连接安全送达。
启用 TLS 的 gRPC 服务端与客户端
gRPC 原生支持 TLS，无需额外封装。服务端需加载证书和私钥，客户端需配置根证书（或跳过验证仅用于测试）。
- 服务端初始化监听时，用 credentials.NewTLS() 包装监听器：
creds, _ := credentials.NewServerTLSFromFile("server.crt", "server.key")
lis, _ := net.Listen("tcp", ":8080")
server := grpc.NewServer(grpc.Creds(creds))
- 客户端连接时，同样用 credentials.NewTLS() 配置凭据：
creds, _ := credentials.NewClientTLSFromFile("ca.crt", "example.com")
conn, _ := grpc.Dial("example.com:8080", grpc.WithTransportCredentials(creds))
立即学习“go语言免费学习笔记（深入）”；
注意：生产环境务必使用有效域名 + 对应证书；开发阶段可用 credentials.NewClientTLSFromCert(pool, "") 加载自签名 CA 证书，避免 insecure 模式。
在 RPC 请求头中透传并验证 JWT
gRPC 元数据（metadata）是传递认证信息的标准方式。客户端将 JWT 放入 authorization header（如 Bearer xxx），服务端中间件统一拦截、解析、校验。
- 客户端调用前注入 Token：
ctx := metadata.AppendToOutgoingContext(context.Background(),
"authorization", "Bearer "+tokenString)
resp, err := client.DoSomething(ctx, req)
- 服务端实现 UnaryInterceptor 验证 Token：
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") }
authHeader := md["authorization"]
if len(authHeader) == 0 { return nil, status.Error(codes.Unauthenticated, "no token") }
tokenStr := strings.TrimPrefix(authHeader[0], "Bearer ")
if !isValidJWT(tokenStr) { return nil, status.Error(codes.Unauthenticated, "invalid token") }
return handler(ctx, req)
}
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
其中 isValidJWT() 应使用 github.com/golang-jwt/jwt/v5 验签、检查过期、比对 audience/issuer 等字段。
结合 TLS 客户端证书增强双向信任（可选但推荐）
若需更高安全等级（如内部系统间强身份绑定），可在 TLS 层启用双向认证（mTLS）。此时服务端不仅验证 JWT，还可从 TLS 连接中提取客户端证书信息，做二次身份映射或白名单校验。
- 服务端 TLS 配置开启 ClientAuth：
creds, _ := credentials.NewTLS(&tls.Config{
Certificates: []tls.Certificate{cert},
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: caPool,
})
- 在拦截器中获取客户端证书信息（例如 CN 或 SAN）：
if peer, ok := peer.FromContext(ctx); ok && peer.AuthInfo != nil {
if tlsInfo, ok := peer.AuthInfo.(credentials.TLSInfo); ok {
if len(tlsInfo.State.VerifiedChains) > 0 {
cert := tlsInfo.State.VerifiedChains[0][0]
log.Printf("Client CN: %s", cert.Subject.CommonName)
}
}
}
可将 CN 与 JWT 中的 sub 字段比对，或作为独立授权依据，实现双因子效果。
Token 管理与刷新建议
JWT 通常设较短有效期（如 15–60 分钟），需配套刷新机制。不建议在每次 RPC 调用前同步刷新 Token（增加延迟和复杂度），更合理的方式是：
- 客户端在 Token 过期前（如剩余 2 分钟）异步刷新，缓存新 Token；
- 服务端返回
UNAUTHENTICATED且错误消息含"token_expired"时，客户端触发刷新并重试原请求； - 使用带
refresh_token的 OAuth2 流程，由独立认证服务签发和续期 JWT。
注意：refresh_token 必须安全存储（如内存、加密本地存储），不可嵌入前端或日志。
基本上就这些。TLS 和 JWT 各司其职，组合起来并不复杂，但容易忽略细节——比如 header 名大小写、证书链完整性、Token 时间漂移处理、错误码语义一致性。把每层验证做到位，RPC 接口就能既开放又可控。
