17370845950

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 头中携带 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 加密+签名（适合内网高敏场景）

在编解码层嵌入认证信息，让非法请求连解码都失败：

• 实现自定义 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），便于动态更新

不复杂但容易忽略：网络认证 ≠ 业务授权，二者应分层叠加。