第三方登录后端流程是什么？Facebook登录流程验证与数据库设计咨询

你梳理的基础流程是通顺的，存在几个容易踩坑的遗漏环节：

• 前端发起FB授权时需要明确申请对应权限，如果你需要获取用户邮箱，必须单独申请email权限，否则FB默认不会返回邮箱字段，直接影响后续的账号匹配逻辑
• FB重定向到后端接口时，返回的是临时授权码code而非直接返回用户信息，需要后端拿code向FB接口交换access token，再用token换取用户信息，passport-facebook已经封装了这两步操作，但排查问题时需要明确这个逻辑
• 后端校验阶段必须校验回调请求携带的state参数，防范CSRF攻击，passport-facebook默认开启了该校验，自定义配置时不要随意关闭
• 现有流程缺少账号绑定的风险确认环节：如果匹配到同邮箱的本站已有账号，建议增加用户确认步骤（比如要求输入原本站账号密码），不要直接默认关联，避免出现邮箱被盗用导致的账号归属纠纷
• 建议增加登录风险校验环节，返回JWT前记录本次登录的IP、设备信息，命中风险规则时可要求二次验证

你遇到的密码非空、同邮箱账号冲突的问题，核心原因是没有拆分本地账号和第三方账号的存储结构，建议按以下逻辑调整： #

1. 表结构拆分 #

不要将本地账号、第三方账号的字段都塞在同一张用户表中，拆分为3张表即可兼容多场景登录需求：

用户主表 users #

存储所有用户通用的基础信息，和登录方式解耦：

• id：主键，用户全局唯一ID
• email：可选，加唯一索引，可留空后续引导第三方登录用户补全即可，注意不同数据库对唯一索引NULL值的处理差异，可通过过滤索引规避重复问题
• 其余通用字段：昵称、头像、注册时间、最后登录时间等自定义字段

本地账号表 local_accounts #

仅存储本站邮箱/手机号注册的账号凭证：

• id：主键，本地账号ID
• user_id：外键，关联users.id，绑定对应的全局用户ID
• email：非空，加唯一索引，作为本地登录的账号
• password：非空，存储加密后的本地账号密码
• 其余本地登录字段：密码过期时间、错误登录次数等自定义字段

第三方账号表 oauth_accounts #

存储所有第三方登录的账号信息，可同时兼容Facebook、Google等多平台登录：

• id：主键，第三方账号ID
• user_id：外键，关联users.id，绑定对应的全局用户ID
• oauth_type：非空，第三方平台标识，比如填facebook
• open_id：非空，对应平台返回的用户唯一ID
• union_id：可选，部分平台提供的多端统一ID，有需求可存储
• access_token/refresh_token/expires_at：可选，存储第三方平台的token，后续需要调用平台开放接口时使用
• 新增联合唯一索引 (oauth_type, open_id)，保证同一个平台的同一个用户只会生成一条记录

2. 账号匹配逻辑 #

按以下流程处理登录请求即可解决同邮箱账号冲突问题：

1. 用户使用Facebook登录时，先拿oauth_type=facebook + 拿到的open_id去oauth_accounts查询，存在记录的话直接获取关联的user_id，生成JWT返回
2. 如果没有查询到对应第三方账号记录，检查Facebook返回的信息中是否包含邮箱：
   • 存在邮箱的话，先去local_accounts查询是否有同邮箱的本地账号：
     • 存在匹配的本地账号：跳转到绑定确认页，要求用户输入本地账号密码，验证通过后将当前第三方账号和该user_id绑定，再返回JWT
     • 不存在匹配的本地账号：先在users表创建新的用户记录，同步昵称、头像等公开信息，再在oauth_accounts中创建对应的第三方账号记录，返回JWT
   • 不存在邮箱的话：直接创建新的users记录和oauth_accounts记录，后续可引导用户补全邮箱绑定本地账号

内容的提问来源于stack exchange，提问作者Kai021195