OAuth 2.0 不适用于微服务间授权，仅应用于用户登录环节（前端→Auth Service）；服务间通信须用 JWT+共享密钥或 mTLS，网关校验 token 并注入 X-User-ID 等可信 header，后端服务不再解析原始 token。
微服务里直接用 OAuth2.0 做“服务间授权”是错的——它不是为这个场景设计的。OAuth2.0 在微服务架构中只该用在「用户登录」环节（即前端 → Auth Service），服务间通信必须用更轻量、更可控的机制，比如 JWT + 共享密钥校验 或 mTLS。
OAuth2.0 不该出现在 service-to-service 调用链里
常见错误是让 Service-A 拿着用户的 access_token 直接调 Service-B 的 API。这会导致三个硬伤：
- Service-B 必须解析并校验 JWT，但无法验证
aud（受众）是否为自己，容易被其他服务冒用 - 令牌过期/刷新逻辑分散到每个服务，运维不可控
- 权限粒度失控：一个 token 可能含多个 scope，Service-B 无法判断当前请求该用哪个 subset
真正该走 OAuth2 流程的，只有最外层入口：用户浏览器或 App → 网关 → Auth Service（/authorize → /token）。之后所有内部调用，应由网关注入可信上下文（如 X-User-ID、X-Scopes），而非透传原始 token。
Auth Service 必须用 golang.org/x/oauth2 + OIDC Provider
如果你自己写 Auth Service（不推荐），至少得满足三点：
立即学习“go语言免费学习笔记（深入）”；
- 用
golang.org/x/oauth2对接标准 OIDC 提供商（如 Keycloak、Dex、Auth0），别自己实现 /token 端点逻辑 -
RedirectURL必须和后台注册值逐字匹配——包括协议、端口、路径末尾斜杠，填错就invalid_request静默失败 - 回调 handler 中必须校验
state：用crypto/rand.Read生成，存入 session 绑定会话 ID，比对用subtle.ConstantTimeCompare，比完立刻删
示例关键配置：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
config := &oauth2.Config{
ClientID: os.Getenv("GOOGLE_CLIENT_ID"),
ClientSecret: os.Getenv("GOOGLE_CLIENT_SECRET"),
RedirectURL: "https://auth.example.com/callback", // ← 必须和 Google Cloud Console 注册值完全一致
Scopes: []string{"https://www.googleapis.com/auth/userinfo.email"},
Endpoint: google.Endpoint,
}
Service-B 如何安全接收用户身份？
Service-B 不该自己解析 JWT，而应信任网关注入的 header：
- 网关在验证 Access Token 后，提取
sub、scope、email等字段，写入X-User-ID、X-Roles等 header - Service-B 只需检查这些 header 是否存在、格式合法（如 UUID 格式），不校验签名
- 若需细粒度鉴权，从 header 读
X-Roles后查本地 RBAC 规则，而不是解析原始 token
这样既解耦，又避免每个服务重复实现 JWT 解析+校验+aud 检查——那些逻辑只该在网关层做一次。
别碰密码模式（Resource Owner Password Credentials）
哪怕你控制着所有服务，也别用用户名密码直连 /token 端点。原因很现实：
- OAuth2.0 规范已将该模式标记为 deprecated，Google、GitHub 等主流平台早已禁用
- 前端要明文处理用户密码，违反最小权限原则
- 无法支持 MFA、设备信任、登录风险评估等现代认证能力
真要兼容老系统，改用 PKCE + Authorization Code Flow，前端生成 code_verifier，后端用 conf.Exchange(ctx, code, oauth2.SetAuthURLParam("code_verifier", verifier)) 完成校验。
最常被忽略的其实是网关层的 audience 校验——如果网关没验证 token 的 aud 字段是否等于自身服务标识，攻击者就能把本该给 Service-A 的 token 拿去调 Service-B，而 Service-B 因为只信网关 header，就放行了。
