OAuth2 access_token合法验证需校验签名、过期时间、颁发者（iss）和受众（aud），JWT格式令牌应使用Provider公钥（推荐JWKS动态获取）验签，严格匹配iss与aud，预留1–2秒exp缓冲，并在中间件中统一拦截各类校验错误返回401。
微服务怎么验证 OAuth2 access_token 是否合法
OAuth2 的 access_token 在微服务间传递时，不能只做“存在性检查”或简单解码，必须完整校验签名、过期时间、颁发者和受众。绝大多数主流 Provider（如 Keycloak、Auth0、Google）返回的 access_token 是 JWT 格式，直接用 github.com/golang-jwt/jwt/v5 解析即可，但漏掉任意一项校验都可能被伪造绕过。
- 从
Authorization: Bearer <token>中提取字符串，注意剥离Bearer前缀（空格不能少） - 用 Provider 公钥（推荐从 JWKS endpoint 动态获取）或对称密钥验签；硬编码 PEM 或字符串密钥仅限开发环境
-
exp必须校验，且建议预留 1–2 秒缓冲（避免服务时钟偏差导致误拒） -
iss（issuer）必须严格等于你对接的 Identity Provider 地址，比如https://auth.example.com，不能只比 host -
aud（audience）必须包含本服务注册的client_id，且不能是通配符（如*）
为什么不能在每个微服务里重复实现 OAuth2 client
微服务不负责发起 OAuth2 授权流程，只负责验证已有的 access_token。把 golang.org/x/oauth2.Config 放进订单服务或用户服务里，不仅冗余，还会引入 RedirectURL、state 管理等完全无关的 Web 层逻辑，徒增出错点。
- OAuth2 授权码流程（/login → /callback）只应在认证网关或统一登录服务中实现
- 下游微服务收到请求后，只做 token 验证 + 权限提取，不参与 code 换 token 过程
- 若某服务误调
conf.Exchange()，会因缺少 session/state/redirect_uri 导致invalid_grant或静默失败 - 密钥管理也更集中：公钥/JWKS 只需一处更新，所有服务自动生效
JWT 验签该用 HS256 还是 RS256
看 token 签发方和验签方是否共享密钥。微服务架构下几乎必须选 RS256，否则一个服务密钥泄露，整个系统令牌可被伪造。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
HS256：签发和验签用同一密钥，适合单体或可信内网，密钥需安全分发到每个服务（风险高） -
RS256：认证服务用私钥签名，所有微服务用公钥验签；公钥可公开分发，私钥离线保管 - 性能上
RS256比HS256慢 10–20 倍，但单次鉴权耗时仍在毫秒级，不影响吞吐 - 别在高频内部 RPC 中频繁签新 JWT——比如服务 A 调 B 前再签一个 token，这属于设计反模式
中间件里容易漏掉的三个校验点
写个 authMiddleware 很容易，但上线后被绕过的漏洞，往往就藏在这三处细节里。
立即学习“go语言免费学习笔记（深入）”；
- 没剥离
Bearer前缀：直接传入带前缀的字符串给jwt.Parse()，解析失败但错误被吞，返回空用户 - 忽略
err == jwt.ErrTokenExpired之外的错误：比如jwt.ValidationError{Errors: jwt.ValidationErrorClaimsInvalid}表示iss或aud不匹配，应统一拦截并返回401 - 没校验
scope或roles字段：token 合法 ≠ 有权限，后续 RBAC 决策依赖 payload 中的声明，字段名依 Provider 而异（Keycloak 用realm_access.roles，Auth0 用permissions）
