OAuth 第三方登录

OAuth 经常被误解成“第三方登录协议”。更准确地说，OAuth 是授权协议：用户允许一个应用访问自己在另一个服务中的部分资源。第三方登录通常是在 OAuth 之上再获取用户身份信息。

为什么需要 OAuth

假设用户想用 GitHub 登录你的系统。最糟糕的做法是让用户把 GitHub 密码交给你。OAuth 的价值是：用户不暴露密码，只授权你的系统获得有限信息。

用户 -> 你的系统 -> GitHub 授权页 -> 授权码 -> 换取 access token -> 获取用户信息

授权码流程

Web 应用常用授权码流程：

1. 用户点击“使用 GitHub 登录”。
2. 系统重定向到 GitHub，带上 client_id、scope、redirect_uri、state。
3. 用户授权后，GitHub 带 code 跳回系统。
4. 系统校验 state，使用 code 换 access token。
5. 系统调用 GitHub 用户信息接口。
6. 本地绑定或创建用户账号。

state 用于防 CSRF，redirect_uri 必须严格匹配白名单，code 必须短期一次性使用。

第三方账号绑定

第三方登录不是拿到外部用户信息就结束。系统要设计账号绑定：

• 第一次第三方登录时，是否自动创建本地账号？
• 如果邮箱已存在，是否允许绑定？
• 用户如何解绑第三方账号？
• 第三方账号被撤销授权后，本地会话如何处理？

本地系统仍然需要自己的用户 ID。不要把外部平台的 openid 当成内部主键，因为用户可能绑定多个身份来源。

Scope 与最小权限

OAuth 的 scope 应该最小化。如果只是登录，不要申请读写仓库、联系人或支付权限。申请越多，用户越不信任，泄露后风险也越大。

第三方 access token 要加密存储，并记录来源、过期时间和刷新方式。如果只是登录用途，通常不需要长期保存第三方 token。

与 SSO 的区别

SSO 多用于同一组织内多个系统共享身份；OAuth 多用于第三方授权和登录。两者可以组合，但不要混淆：

• SSO 关注统一认证体验。
• OAuth 关注用户授权某个应用访问某些资源。

第三方身份接入后，账号风险更复杂。下一章通过 MFA 增强高风险场景的身份确认。