Golang 编写一个支持多协议适配的认证中心-Golang-PHP中文网

不能直接用 http.handler 做多协议认证入口，因其仅支持 http 流量，无法兼容 grpc、websocket 等协议，强行统一会导致语义丢失、流控失效及元数据传递中断。

为什么不能直接用 `http.handler` 做多协议认证入口

因为 http.handler 只能处理 http 流量，而认证中心常需同时接入 grpc、websocket、甚至 mqtt 或自定义 tcp 协议。硬塞所有协议到 http 路由里会导致协议语义丢失（比如 grpc 的 status.code 被转成 http 状态码后不可逆），也破坏了各协议的流控、超时、元数据传递机制。

实操建议：

按协议分层：每种协议单独起一个监听服务（http.Server、grpc.Server、net.Listener），共用同一套认证逻辑层（如 AuthnService 结构体）
避免在协议层做业务判断，例如不要在 HTTP handler 里解析 JWT claims 后再决定调哪个 gRPC 方法——统一交给 AuthnService.Verify() 返回 UserID 和 Scopes，协议层只负责透传原始凭证（Authorization header、metadata.MD、或自定义二进制 token 字段）
注意 gRPC 的 UnaryInterceptor 和 StreamInterceptor 必须分别实现，流式方法（如双向 streaming）的上下文生命周期和 unary 不同，漏掉 stream 拦截器会导致长连接绕过认证

`AuthnService.Verify()` 应该接收什么参数、返回什么

它不该绑定任何协议细节。输入应是抽象凭证载体，输出是结构化认证结果，否则适配新协议时就得改核心逻辑。

推荐签名：

type AuthnResult struct {
    UserID   string
    Scopes   []string
    Expires  time.Time
    Metadata map[string]string // 如 issuer、client_id，供下游鉴权用
}
func (a *AuthnService) Verify(ctx context.Context, cred Credential) (*AuthnResult, error)

其中 Credential 是接口：

cred.Type() 返回 "jwt" / "api_key" / "oauth2_code"，用于路由到对应解析器
cred.Raw() 返回原始字节（HTTP header 值、gRPC metadata value、TCP 包 payload），不提前 decode
HTTP 适配器构造 cred 时取 r.Header.Get("Authorization")；gRPC 适配器从 metadata.FromIncomingContext(ctx) 提取 "authorization" key；MQTT 适配器则从 CONNECT packet 的 username/password 或 properties 中提取

JWT 解析器为什么必须校验 `aud` 且区分环境

生产环境若忽略 aud（Audience），攻击者可复用其他系统的 JWT 访问你的认证中心，甚至伪造 iss（Issuer）绕过白名单。更隐蔽的问题是：本地开发常用 hs256 + 硬编码密钥，但上线必须切到 rs256 + 公私钥对，且公钥需通过 JWKS 端点动态获取——否则密钥轮换时要重启所有服务。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

实操要点：

初始化 AuthnService 时传入 audience 字符串切片，每个协议适配器调用 Verify() 前明确指定当前协议的预期 aud（如 ["https://api.example.com", "grpc://auth.example.com"]）
JWT 解析器内部用 github.com/golang-jwt/jwt/v5，校验时显式传入 WithAudience(allowedAud...) 和 WithIssuer(allowedIss...)
避免用 ParseUnverified()，哪怕只是调试——它跳过签名验证，等于裸奔

如何让 gRPC 和 HTTP 共享同一套 token 刷新逻辑

HTTP 用 Cookie 或响应头 Set-Cookie，gRPC 没有 Cookie 概念，只能靠客户端在 metadata 里手动追加新 token。如果两套刷新逻辑独立实现，容易出现状态不一致（如 HTTP 刷新成功但 gRPC 还在用旧 token 直到过期）。

解决方案是把刷新动作下沉到 AuthnService.Refresh()，协议适配器只负责「触发」和「透传」：

HTTP 适配器收到 /v1/auth/refresh POST，解析 body 中的 refresh_token，调 svc.Refresh(ctx, refreshToken)，成功后写新 access_token 到响应头或 Cookie
gRPC 适配器在拦截器中检测到 access_token 即将过期（比如 Expires.Before(time.Now().Add(5 * time.Minute))），主动调 svc.Refresh()，并将新 token 放入 metadata.Pairs("authorization", "Bearer "+newToken) 返回给客户端
关键约束：refresh_token 必须一次性使用（用后即废），且服务端需记录其绑定的 user_id + device_fingerprint，防止被盗刷

多协议下最易被忽略的是错误传播粒度——HTTP 可以返回 401 + JSON 错误体，gRPC 必须转成 status.Error(codes.Unauthenticated, "invalid refresh token")，否则客户端 grpc-go 默认无法识别。别指望前端或移动端 SDK 能自动处理跨协议错误格式。