当前位置：首页 >专题 >Go OAuth 2.0 与 OIDC 身份认证实战专题
Go OAuth 2.0 与 OIDC 身份认证实战专题
官方入口与协议资料
先以标准和 Go 官方库确认认证授权语义
OAuth 2.0 Security Best Current Practice
OAuth 2.0 Security BCP 与 RFC 9700 的官方入口，覆盖 PKCE、redirect URI、token 和客户端安全。
OpenID Connect Core 1.0
OpenID Connect 核心规范，定义基于 OAuth 2.0 的身份认证、ID Token 与 Claims。
Go x/oauth2 官方包文档
Go 官方 oauth2 包文档，覆盖 Config、AuthCodeURL、Exchange、TokenSource 与 PKCE 辅助 API。
OAuth 2.0 RFC 6749
OAuth 2.0 授权框架核心 RFC，定义四类角色与访问令牌。
OAuth 2.0 Bearer Token RFC 6750
Bearer Token 使用规范，说明 Authorization 请求头、错误响应和令牌泄露风险。
Go OAuth2 源码仓库
golang.org/x/oauth2 的官方源码、变更和问题追踪入口。
站内身份认证实战路线
从第三方登录到 API、RPC 和权限边界
OAuth 与 OIDC 常见问题
把协议边界落实到代码评审和上线检查
OAuth 2.0 和 OpenID Connect 是一回事吗？
不是。OAuth 2.0 是授权框架；OIDC 建立在 OAuth 2.0 之上，增加身份认证、ID Token 和 UserInfo 语义。登录场景应按 OIDC 校验身份，不要仅凭 Access Token 推断用户登录。
为什么授权码流程还需要 PKCE 和 state？
state 用于绑定发起请求与回调，降低 CSRF 和回调串线风险；PKCE 用 code_verifier 绑定授权码交换，降低授权码被截获后的滥用风险，并应严格校验 redirect_uri。
收到 JWT 后只验证签名就够了吗？
不够。还应限制算法和签发者，校验 audience、过期时间、not-before、必要 Claims 以及密钥轮换；权限判断还要结合 Scope、角色、租户和资源归属。
Access Token 和 Refresh Token 应该怎么保存？
应按客户端类型和威胁模型选择，服务端 Web 应用尽量使用受保护的服务端会话，浏览器端避免把长期 Refresh Token 暴露给脚本；令牌应限制 Scope、缩短有效期并通过 TLS 传输。
相关专题
继续查看相近方向内容
-
- Go doc 注释中的示例如何被测试工具识别
- 4分钟前 170浏览
-
- 检索结果重复时如何做去重和来源合并
- 5分钟前 484浏览
-
- Go 编译缓存目录异常膨胀如何安全清理
- 8分钟前 412浏览
-
- Lovart画布怎么用文字和形状搭海报？Text、Shapes与图层整理步骤
- 10分钟前 454浏览
-
- VS Code 调试容器内程序时断点不生效怎么办
- 11分钟前 413浏览
-
- Go generate 如何把生成步骤和源码目录绑定
- 15分钟前 321浏览
-
- Redis ACL 用户权限不足时怎么定位具体命令
- 16分钟前 134浏览
-
- Go 竞态修复后吞吐下降如何确认是锁竞争
- 22分钟前 430浏览
