优先选gocloak用于需调用keycloak管理api的场景（如查用户、绑角色），选标准oauth2包用于纯前端跳转+后端校验token的web应用；前者功能全但重，后者轻量可控。
用 gocloak 还是手撸 oauth2？看你的认证场景
直接结论：内部管理后台、CLI 工具、需要调 Keycloak 管理 API（如查用户、绑角色）——选 gocloak；纯前端跳转登录 + 后端校验 token 的 Web 应用 ——用标准 golang.org/x/oauth2 更轻量、更可控。
原因很简单：gocloak 是对 Keycloak REST API 的完整封装，它能帮你创建用户、分配角色、刷新令牌、甚至调 /admin/realms/{realm}/users，但代价是引入了大量 HTTP 客户端逻辑和依赖（比如 resty）；而 oauth2 包只管授权码流程的三步（重定向 → 换 token → 解析 ID Token），不碰管理功能，也更利于你自定义中间件或集成 JWT 校验逻辑。
- 如果你的 Go 服务要支持「管理员后台批量导入用户」或「登录后动态查用户所属 realm 角色」，
gocloak.Login()和client.GetUsers()能省掉至少 200 行胶水代码 - 但若只是「用户点登录 → 跳 Keycloak → 回来校验
id_token→ 写 session」，硬上gocloak反而多出 token 存储、上下文传递、错误映射等隐性复杂度 -
gocloak默认用context.Background()发请求，生产环境必须显式传带 timeout 的 context，否则超时会卡死 goroutine
oauth2.Config 配错最常导致 invalid_request 或 unauthorized_client
Keycloak 对 OAuth2 参数极其敏感，90% 的“跳转后报错”都源于客户端配置和代码不一致。不是 Keycloak 不行，是你没对齐。
-
RedirectURL必须和 Keycloak 后台Valid Redirect URIs完全一致，包括末尾斜杠 ——http://localhost:8080/callback和http://localhost:8080/callback/是两个不同地址 -
Scopes至少含"openid"，否则 Keycloak 返回的是 OAuth2 access_token，不是 OIDC id_token，后续解析会失败；加"profile"才能在 ID Token 里拿到name、preferred_username - Client 的
Access Type设为confidential时，ClientSecret必须传；设为public（如纯前端 Vue App）则不能传 Secret，否则 Keycloak 直接拒掉 token 请求 - AuthURL 和 TokenURL 中的 realm 名必须小写且完全匹配，
MyRealm和myrealm会被当成两个 realm
token 校验别只信 Parse()，得验 issuer、audience 和 signature
很多人用 jwt.Parse() 成功就以为万事大吉，结果发现伪造的 token 也能过 —— 因为没配好 keyfunc，或者漏了关键 claim 校验。
Keycloak 发的 ID Token 是标准 OIDC token，必须同时验证三项：
-
iss（issuer）必须是"https://keycloak.example.com/auth/realms/your-realm"，硬编码写死，防止其他 issuer 冒充 -
aud（audience）必须包含你的ClientID，Keycloak 默认把 client_id 当作 audience，不匹配则拒绝 - signature 必须用 Keycloak realm 的公钥验签，不是用你自己随便设的
[]byte("secret")—— 否则所有 token 都能伪造
正确做法是先从 Keycloak 获取 JWKS（https://keycloak.example.com/auth/realms/your-realm/protocol/openid-connect/certs），再用 github.com/lestrrat-go/jwx/v2/jwk 解析并传给 jwt.Parse() 的 keyfunc。手写 keyfunc 返回固定密钥，只适用于开发测试。
gocloak 的 Login() 不适合浏览器登录流程
gocloak.Login() 是模拟表单提交的密码直连方式，它把用户名密码明文发给 Keycloak 的 /realms/{realm}/protocol/openid-connect/token 接口 —— 这在 CLI 或服务间调用没问题，但在 Web 场景下等于让用户密码经过你的后端，既违反最小权限原则，也无法支持 MFA、WebAuthn 等增强认证。
真实浏览器登录必须走标准 Authorization Code Flow：
- 用户访问
/login→ 重定向到 Keycloak AuthURL（带response_type=code） - Keycloak 认证完 → 302 回调你的
/auth/callback - 你的 handler 用 code 换 token → 解析 ID Token → 建立本地 session
这时候 gocloak 的价值在于后续：比如用户登录后，你想查他有没有 admin role，就用 client.GetRoleMappings()，而不是再拼一次 HTTP 请求。
最容易被忽略的一点：Keycloak 的 token endpoint 默认不返回 refresh_token，除非你在 client 配置里打开 Standard Flow Enabled 并勾选 Offline Access（如果需要长期刷新）；还有，所有涉及 Realm 名、Client ID、URL 的字符串，建议从环境变量读取，别硬编码 —— 一个拼错，调试两小时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
