Go中实现RPC安全认证需在服务端拦截请求并验证身份，主要方式有：1. HTTP Header Token认证；2. 自定义Codec加签；3. TLS双向证书；4. 方法级权限控制。
在 Go 中实现 RPC 安全认证，核心是**在服务端拦截请求、验证身份，并拒绝未授权调用**。标准 net/rpc 本身不内置认证机制，需手动在传输层或逻辑层增强。下面给出实用、可落地的几种方式，兼顾简洁性与安全性。
1. 基于 HTTP Header 的 Token 认证（推荐入门）
若使用 http.ServeHTTP 暴露 RPC 服务（如 rpc.ServeHTTP），可在中间件中校验 token：
- 客户端每次请求在
Authorization: Bearer <token></token>头中携带 JWT 或随机 token - 服务端用
http.Handler包裹默认 RPC handler，解析并校验 token 有效性（例如查 Redis 或验签名） - 校验失败直接返回
http.StatusUnauthorized，RPC 请求不会进入实际方法
示例关键片段：
handler := http.NewServeMux()
handler.Handle("/rpc", &authHandler{next: rpc.DefaultServer.HTTPHandler()})
type authHandler struct {
next http.Handler
}
func (h *authHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
auth := r.Header.Get("Authorization")
if !isValidToken(strings.TrimPrefix(auth, "Bearer ")) {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
h.next.ServeHTTP(w, r)
}
2. 自定义 RPC Codec 加密+签名（适合内网高敏场景）
在编解码层嵌入认证信息，让非法请求连解码都失败：
立即学习“go语言免费学习笔记（深入）”；
- 实现自定义
gob.Encoder/Decoder或json.Encoder/Decoder，在消息体外层添加nonce+hmac签名字段 - 服务端解码前先验签，签名无效则 panic 或返回错误，
net/rpc会自动终止该连接 - 配合 TLS 使用更稳妥（见下一条），避免密钥/签名被嗅探
注意：此法对客户端强约束，需双方使用同一加签逻辑，适合可控环境（如微服务间通信）。
3. 强制 TLS + 双向证书认证（生产首选）
最彻底的方式——把认证下沉到 TCP 层，由 TLS 握手完成身份确认：
- 服务端启动
http.Server时配置TLSConfig.ClientAuth = tls.RequireAndVerifyClientCert - 分发唯一客户端证书（含私钥），服务端通过
tls.Config.VerifyPeerCertificate校验 CN 或扩展字段（如service=payment） - 客户端使用证书发起 HTTPS 连接，
rpc.NewClient需基于http.Transport构建，复用该 TLS 连接
优势：零侵入业务逻辑，所有未持有效证书的连接在建立阶段就被拒，性能开销低且防中间人攻击。
4. 方法级权限控制（补充逻辑层细粒度管控）
即使网络层已认证，仍建议在 RPC 方法内部做最小权限检查：
- 将用户身份（如从 token 解析出的
userID、role）透传至方法上下文（可通过自定义结构体参数或context.Context） - 在每个 RPC 方法开头调用权限检查函数：
if !canAccess(user, "AdminService.DeleteUser") { return errors.New("forbidden") } - 权限规则可存于内存 map、Redis 或外部策略服务（如 OPAL），便于动态更新
不复杂但容易忽略：网络认证 ≠ 业务授权，二者应分层叠加。
