go-oidc初始化失败因Provider URL误用授权端点而非issuer，正确issuer需支持/.well-known/openid-configuration；RedirectURL须字节级匹配注册值；ID Token校验必须用provider.Verifier而非直接解析JWT。
go-oidc 初始化失败：Provider URL 必须是 issuer，不是授权端点
常见错误是把 https://accounts.google.com/o/oauth2/auth 这类授权端点 URL 当作 issuer 传给 oidc.NewProvider，结果 panic 或返回 provider: failed to fetch provider config。issuer 必须是 OpenID Connect 提供商的根地址，比如 Google 是 https://accounts.google.com，Auth0 是 https://YOUR_DOMAIN.auth0.com（不含 /authorize 或 /oauth2 路径）。
验证方法很简单：访问该 URL + /.well-known/openid-configuration，应返回标准 JSON 配置。如果 404 或格式不对，说明 issuer 错了。
- Google 的 issuer 是
https://accounts.google.com - GitHub 的 issuer 是
https://github.com/login/oauth/authorize？错——实际是https://github.com（需确认其/.well-known/openid-configuration是否存在；注意 GitHub OIDC 支持有限，仅适用于 Actions，不开放给第三方应用） - Auth0 的 issuer 是
https://YOUR_DOMAIN.auth0.com，不是https://YOUR_DOMAIN.auth0.com/oauth2
回调校验失败：RedirectURL 必须与注册值完全一致
oauth2.Config.RedirectURL 和 OIDC 提供方控制台里填的 “Allowed Callback URLs” 必须字节级相同。多一个斜杠、少一个协议、端口没写全，都会触发 invalid_request: redirect_uri_mismatch。
本地开发最常踩的坑是：http://localhost:8080/callback 注册了，但代码里用了 http://127.0.0.1:8080/callback ——二者 DNS 解析不同，OIDC provider 视为两个不同 URI。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
http://localhost:8080/callback，别切 IP 地址 - 生产环境必须用 HTTPS，且 scheme/host/port/path 全部匹配，例如
https://app.example.com/callback - 若走 Nginx 反向代理，Go 中需用
r.Header.Get("X-Forwarded-Proto")和X-Forwarded-Host动态构造真实RedirectURL，不能硬编码
ID Token 校验被绕过：必须用 verifier，不能只解析 JWT
golang.org/x/oauth2 只负责换 token，不校验 id_token 真实性。直接用 jwt.Parse 解析 id_token 字符串，等于跳过签名、iss、aud、exp、nonce 等全部校验，攻击者可伪造 token 登录。
正确做法是用 provider.Verifier：
verifier := provider.Verifier(&oidc.Config{ClientID: "your-client-id"})然后传入原始 id_token 字符串调用 verifier.Verify(ctx, rawIDToken)。它会自动拉取 JWKS、验证 RS256 签名、检查 aud 是否匹配、exp 是否过期等。
-
aud必须传注册时的client_id，不是 domain 或其他字符串 - 生产环境务必加时钟偏移容忍：
jwt.WithAcceptableSkew(10 * time.Second)，否则服务器时间不同步会导致token is expired - 若用了
nonce，校验器会自动检查；没传则跳过 —— 但建议始终启用nonce防重放
API 请求 vs 页面请求：401 和 302 别混用
中间件里对未登录请求一律 http.Redirect(w, r, "/login", http.StatusFound)，前端 fetch API 会静默收到 302，但不会跳转，最终拿到空响应或 CORS 错误，调试时很难定位。
得区分请求类型：
- 检查
r.Header.Get("Accept")是否包含application/json - 或按路径前缀判断，如
strings.HasPrefix(r.URL.Path, "/api/") - HTML 请求返回 302 到登录页；JSON 请求返回
http.StatusUnauthorized+ 错误 JSON，例如{"error": "unauthorized", "message": "login required"}
state 参数也得防重放：生成时带时间戳和随机数，存储在 session 或 Redis，校验时检查是否 ≤ 5 分钟，且用 crypto/subtle.ConstantTimeCompare 比对，避免时序攻击。
