微服务只负责验证access_token，不参与OAuth2.0授权流程；授权码模式必须由独立Auth Server完成，业务微服务仅校验JWT的signature、iss、aud三项及exp/nbf/iat时间字段和scope权限。
微服务本身不跑 OAuth2.0 授权流程，只做 token 校验——这是最常被误解的前提。真正的 Authorization Code Flow（登录跳转、用户授权、code 换 token）必须由独立的 Auth Server（如 Keycloak、Auth0 或自建网关）完成，你的业务微服务只负责接收并验证传入的 access_token。
为什么微服务不该调用 oauth2.Config.Exchange()
调用 oauth2.Config.Exchange() 意味着你的微服务在处理用户登录跳转、持有 ClientSecret、管理 state、拼 redirect_uri —— 这违反了职责分离原则，也带来密钥泄露、CSRF 防护缺失、多环境配置混乱等风险。
- 微服务通常无 Web 入口，没有 session、不处理重定向，
Exchange()所需的code和上下文根本不存在 -
ClientSecret若硬编码或注入到每个微服务中，一旦某服务被攻破，整个认证体系即失效 - 不同微服务若各自实现 Exchange 逻辑，会重复造轮子：state 存储方式不一、redirect_uri 拼写不一致、scope 解析口径不同
- 真实生产环境要求 token 由统一 Auth Server 签发并支持 JWKS 密钥轮换，微服务自己换 token 无法接入该机制
access_token 到底该怎么验？漏掉这三项就等于没鉴权
绝大多数 OAuth2 提供方（Google、Keycloak、Auth0）返回的 access_token 是 JWT。只调用 jwt.Parse() 成功远远不够，必须同步校验以下三项，缺一不可：
- signature：用 Auth Server 提供的公钥（JWKS endpoint）验签，不能跳过、不能用硬编码 PEM、不能 fallback 到 HS256
-
iss（issuer）：必须严格等于你信任的 Auth Server 地址，例如
"https://auth.example.com"；若忽略，任意 OIDC 提供方的 token 都能通过 -
aud（audience）：必须包含且仅包含你服务注册的
client_id，不能是通配符"*"或空数组
额外但关键：exp、nbf、iat 时间字段必须校验；scope 字段需提取后用于后续 RBAC 决策，不能只解析不检查。
立即学习“go语言免费学习笔记（深入）”；
JWT 中间件里最容易静默失败的三件事
很多团队封装了“JWT 鉴权中间件”，却在线上长期容忍无效请求通过，问题往往藏在细节里：
- 没剥离
Bearer前缀：从Authorizationheader 取值时直接用r.Header.Get("Authorization")，结果拿到的是"Bearer eyJhb..."，导致 parse 失败或 panic - 没设
ValidateExp：jwt.Parser默认不校验exp，需显式传入jwt.WithValidator(jwt.ValidateExp)或手动检查claims.ExpiresAt - 错误响应体不统一：有的返回
401 {"error": "invalid token"}，有的 panic 后返回 500，前端无法区分是未登录还是系统故障
建议把解析、验签、字段校验、scope 提取全部收进一个函数，返回结构化错误类型（如 ErrInvalidToken、ErrExpired），再由中间件统一转成 401/403 响应。
本地开发和生产环境的 RedirectURL 陷阱
这个坑不发生在微服务里，但会卡死整个流程起点——如果你的网关或登录服务用了 golang.org/x/oauth2，RedirectURL 错一个字符就会让 Exchange() 返回 invalid_request，且错误体里才写明原因。
- 本地必须填
http://localhost:8080/callback，不是http://127.0.0.1:8080/callback，也不是少斜杠的http://localhost:8080/callback/ - 微信要求
redirect_uri在AuthCodeURL()参数中 URL 编码（如%2Fcallback），GitHub 明确拒绝编码过的值——不能共用一套逻辑 - 多环境靠
os.Getenv("OAUTH_REDIRECT_URL")注入，别在代码里写if env == "prod" { ... }，容易漏改或分支不一致
调试时最有效的方法：用 curl -v 直接请求授权 URL，看 Location header 是否跳转到你预期的回调地址——比查日志快十倍。
