Flutter对接Django后端实现社交登录的方案是否安全及优化方法

你当前的实现逻辑符合OAuth2三方登录的核心设计原则，没有把身份校验逻辑完全放在前端，基础安全性是达标的，但仍存在几个可被利用的安全漏洞：

• 未校验Google返回凭证的受众：仅用access token拉取用户信息就完成登录的话，攻击者可以用其他应用申请的Google OAuth凭证生成的access token，伪造用户身份登录你的系统
• 缺乏凭证有效性前置校验：直接调用Google接口拉取用户信息的逻辑，没有提前校验token的过期时间、发行方属性，容易被重放攻击利用
• 传输层风险未做强制约束：如果前端向后端传输access token时未强制走HTTPS，会存在token被中间人窃取的风险
• 接口无防护规则：不对该接口做频次限制的话，会面临攻击者批量枚举token撞库的风险

推荐你按以下逻辑调整实现，安全性和性能都会有明显提升：

• 用ID Token替代Access Token做身份凭证
  Google返回的ID Token是经过签名的JWT格式凭证，本身包含用户的唯一身份标识、发行方、受众、过期时间等核心字段，后端可以直接用Google的公开密钥离线完成校验，不需要每次都向Google发起接口请求，性能和安全性都更高。你可以直接从google_sign_in包的返回结果中获取idToken字段，发送给后端即可。
• 补全后端校验规则
  拿到ID Token后必须完成以下几项强制校验，全部通过才允许登录：
  • iss（发行方）字段必须为https://accounts.google.com或者accounts.google.com
  • aud（受众）字段必须和你在Google Cloud控制台申请的对应端（Android/iOS）的OAuth客户端ID完全匹配
  • exp（过期时间）必须大于当前服务器时间
  • 用sub（用户唯一标识）字段作为用户表的关联唯一键，不要用邮箱做关联，避免用户修改Google邮箱后账号丢失
• 补充额外安全规则
  • 前端向后端传输token时，放在请求头的Authorization字段，使用Bearer 前缀，不要放在URL参数里，避免被服务器日志意外泄露
  • 后端生成的自有认证token使用DRF的短有效期Token，搭配Refresh Token使用，降低token泄露后的影响范围
  • 给社交登录接口添加限流规则，比如单IP每分钟最多请求10次，避免暴力攻击

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