OAuth2负责发令牌（常为JWT格式），微服务仅验证JWT而不参与授权流程；正确分工是网关完成OAuth2全流程并透传JWT，微服务校验其iss、aud、exp字段并动态拉取JWKS。
微服务架构下，OAuth2 不是用来替代 JWT 的，而是负责“发令牌”，JWT 是它最常发的令牌格式；你的微服务只管验证 JWT，不参与 OAuth2 流程本身。
微服务只验证 JWT，不处理 OAuth2 授权流程
OAuth2 授权码流程（跳转 → 换 token → 拿用户信息）必须由前端或网关层完成，微服务作为资源服务器，只接收已签发的 access_token 并校验。强行在每个微服务里重复实现 oauth2.Config.Exchange 会导致密钥泄露、重定向混乱、state 校验失效等严重问题。
- 正确分工：API 网关或登录服务完成 OAuth2 全流程，生成 JWT 后透传给下游微服务
- 微服务职责：从
Authorization: Bearer <token>提取字符串，用公钥（JWKS）或对称密钥验证签名 - 错误做法：在订单服务里也配
ClientID/ClientSecret去调/oauth/token—— 这等于把敏感凭证散落在各处
JWT 校验必须检查 iss、aud、exp 三个字段
只校验 exp 是常见漏洞点。攻击者可用其他 OAuth2 提供方（比如测试环境 Keycloak）签发的合法 JWT，绕过鉴权直接访问生产服务。
-
iss（issuer）：必须严格匹配你信任的授权服务器地址，如"https://auth.example.com" -
aud（audience）：必须包含当前微服务标识，如"order-service"，避免 token 被跨服务滥用 -
exp（expiration）：建议设为短时效（15–60 分钟），配合刷新机制，而非依赖长期有效 token - 推荐库：
github.com/golang-jwt/jwt/v5，用jwt.ParseWithClaims显式传入校验规则
RedirectURL 必须和平台后台注册值完全一致
这是本地调试失败的头号原因。GitHub/GitLab/Google 要求 RedirectURL 字符串一字不差，包括协议、端口、路径末尾斜杠 —— 微服务本身不参与该 URL 构造，但网关或登录服务初始化 oauth2.Config 时若填错，整个流程会在第一步静默失败。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 本地开发只能用
http://localhost:8080/auth/callback，且必须在 GitHub 后台填相同字符串（不能写127.0.0.1或省略端口） - 生产环境必须用 HTTPS，且域名与证书一致；
https://api.example.com/callback/和https://api.example.com/callback视为不同 URL - 微信、飞书等非标平台需手动构造
oauth2.Endpoint，注意其AuthURL和TokenURL返回字段名（如微信返回access_token，不是access_token）
state 参数必须由网关/登录服务全链路闭环管理
微服务不生成也不校验 state，但它依赖上游正确传递的用户上下文。如果网关漏掉 state 存储或比对，攻击者可伪造回调请求，把恶意 code 换成有效 token，进而冒充任意用户。
- 生成：用
crypto/rand.Read读 32 字节，再base64.URLEncoding.EncodeToString编码 - 存储：存入带签名的 session cookie 或 Redis，key 为
"oauth_state:" + sessionID，**不可全局共享** - 比对：回调到达网关后，立即用
subtle.ConstantTimeCompare校验，比对完立刻删除该 state - 切记：
state只防 CSRF，不承载业务参数；next 跳转地址、用户 ID 等应走后端 session 或加密 JWT
真正容易被忽略的是：微服务拿到的 JWT 未必来自你信任的 OAuth2 提供方 —— 它可能被上游网关错误转发、被中间人篡改、或因 JWKS 密钥轮换未同步导致验签失败。所以每次启动时必须能动态拉取并缓存 JWKS，且要设 fallback 机制，而不是硬编码公钥。
