sso模块不建议自己封装，应优先集成go-oidc等成熟库；需严格校验aud/iss、缓存provider、用redis持久化session、主动刷新token，并避免手写saml解析。
SSO模块要不要自己封装？先看标准协议支持度
绝大多数企业级SSO不是靠“从零写”撑起来的，而是基于成熟协议栈（OIDC / SAML2）复用。Go生态里 go-oidc 和 onelogin/saml 已覆盖90%以上IDP对接场景。自己封装前先确认：你们的统一身份平台是否强制要求私有协议？有没有现成的OpenID Connect Discovery Endpoint？如果答案是“否”，直接集成 go-oidc 比重写认证流程更稳妥——它已通过Auth0、Azure AD、Keycloak等主流IDP的长期验证。
用 go-oidc 实现OIDC客户端的关键三步
不是调个VerifyIDToken就完事。真实环境里，token校验、用户同步、session管理必须闭环：
-
Provider初始化必须带缓存：每次请求都重新fetch
/.well-known/openid-configuration会拖慢首屏。用http.Client配Transport+Cache（如cache.New），或直接复用go-oidc内置的Provider缓存逻辑 -
ID Token校验要严格比对
aud和iss：很多团队漏掉aud校验，导致恶意应用伪造token。务必传入你注册时分配的client_id给Verifier构造函数 -
UserInfo获取别用裸HTTP：直接调
provider.UserInfo，它自动处理Bearer头、token刷新、scope校验；手写HTTP请求容易忽略Authorization: Bearer xxx或错用access_token类型
示例片段：
verifier := provider.Verifier(&oidc.Config{ClientID: "your-client-id"}) 这里的 ClientID 必须和IDP后台注册的一致，否则 VerifyIDToken 直接返回 oidc: unable to verify ID Token 错误。
Session持久化怎么避开常见坑
SSO登录态不等于HTTP session，但业务系统仍需本地session维持上下文。问题常出在：
-
用内存session（如
gorilla/sessions默认CookieStore）上线即崩：多实例部署时用户反复跳转登录页。必须切到Redis或DB-backed store，且key前缀加租户标识（如sso:tenant-a:sess:） -
过期时间不能只信token的
exp：IDP可能提前吊销token，但本地session还活着。建议每30分钟用provider.UserInfo主动校验一次access_token有效性，失败则清空本地session -
Logout不同步：OIDC RP-Initiated Logout需要向IDP发起POST请求并携带
id_token_hint。漏掉这步，用户点退出后token仍在IDP侧有效
为什么SAML2在Go里通常不推荐手写解析
onelogin/saml 库能跑通基础流程，但企业级场景下它暴露太多XML细节：签名验证依赖 xmlsec 绑定、证书加载路径硬编码、NameID格式需手动映射。更现实的做法是：
- 让IDP提供OIDC替代方案（多数现代IDP都支持）
- 若必须用SAML，用反向代理把SAML断言转成OIDC token（如用
authelia或自建gateway） - 真要直连，至少把证书、元数据URL、ACS URL做成配置项而非代码常量，避免每次IDP升级都要改代码
特别注意：SAML响应里的 NotOnOrAfter 时间戳必须用UTC解析，Go的 time.Parse 默认按本地时区，容易校验失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
