必须走授权码流程并用oidc.Verifier校验id_token，因jwt.Parse()仅验签名不校iss/aud/exp，issuer URL须严格匹配Keycloak realm路径且大小写敏感，Provider须全局复用。
直接说结论：用 go-oidc 对接 Keycloak/Auth0/Okta 等标准 OIDC 提供商，必须走授权码流程 + oidc.Verifier 校验 id_token，不能只靠 jwt.Parse() 或自己拼 aud。
为什么 oidc.NewProvider() 会 panic 或静默失败
根本原因是 issuer URL 不合规。Keycloak 的 issuer 必须是 https://keycloak.example.com/auth/realms/myrealm 这种形式——不带 /.well-known/openid-configuration 后缀，也不能漏掉 /auth/realms/ 路径段。
- 错例：
https://keycloak.example.com（少 realm 路径）、https://keycloak.example.com/auth/realms/myrealm/.well-known/openid-configuration（多了一截，go-oidc 内部会自动补） - 大小写敏感：
MyRealm≠myrealm，Keycloak 后台配置和代码里必须完全一致 - 协议和端口也要对齐：本地开发用
http://localhost:8080，就别在 issuer 里写https；生产环境用了https，issuer 就不能是http
回调能进但 verifier.Verify() 报 invalid issuer 或 invalid audience
这基本不是代码逻辑问题，而是配置错位。Keycloak 对 RedirectURL 和 id_token.aud 的校验极严，差一个斜杠、一个协议、一个端口都失败。
-
oauth2.Config.RedirectURL必须和 Keycloak 后台 “Valid Redirect URIs” 一模一样，包括末尾斜杠：http://localhost:8080/callback/≠http://localhost:8080/callback -
id_token.aud字段必须严格等于你注册 client 时填的Client ID，不是Client Name，也不是随便起的字符串 - Scopes 至少要含
"openid"，否则 Keycloak 只返回access_token，没有id_token，后续verifier.Verify()直接 panic
为什么不能用 jwt.Parse() 替代 oidc.Verifier.Verify()
jwt.Parse() 只做签名和基础字段解析，它不验证 iss 是否匹配 issuer、不检查 aud 是否等于你的 client_id、也不做时钟偏移容错（默认 ±60 秒）。OIDC 场景下跳过 oidc.Verifier 就等于放弃协议安全边界。
立即学习“go语言免费学习笔记（深入）”；
-
oidc.Verifier自动校验三要素：iss（必须等于初始化 Provider 时传的 issuer）、aud（必须等于你的client_id）、exp（含时钟偏移容忍） - Provider 实例必须全局复用，不能每次请求都调
oidc.NewProvider()，否则性能断崖下跌——内部会缓存 discovery 文档和 JWKS 密钥 - 如果还要查用户信息或管理角色，再引入
gocloak；纯登录+token 校验，go-oidc足够，混用反而增加冗余逻辑和风险
真正容易被忽略的是时间同步——服务器系统时间偏差超过 60 秒，verifier.Verify() 就会拒掉所有 token，连错误提示都不明显，得盯日志里的 Token is expired 或 invalid claims 才能定位。
