基于allauth/dj_rest_auth，Google OAuth2无需后端知晓client_id、client_secret为何仍能运行？

你这种只配置client_id、不填client_secret的做法完全不安全，核心风险有这几点：

• 无法确认access_token的真实性：Google的access_token虽然能解码出用户信息，但要证明它确实是Google颁发给你的应用的，必须用client_secret去Google的令牌验证接口做校验。如果跳过client_secret，恶意用户可以伪造一个包含正确client_id的假token，后端会直接把这个假token当成合法凭证创建用户，导致身份伪造漏洞。
• 违背OAuth2安全规范：你现在的流程属于隐式授权模式，这种模式本来就只推荐纯前端应用使用——因为access_token会直接暴露在前端，容易被窃取。而你是有后端服务的场景，正确的做法应该用授权码流程：前端拿授权码而非access_token，再把授权码传给后端，由后端结合client_secret去Google换取合法的access_token，这才能保证token的传输和验证都在安全的后端环境里进行。
• 绕过了dj_rest_auth的安全校验：dj_rest_auth要求配置SocialApp的client_secret，就是为了让后端能和Google的认证服务器做双向验证，确保整个流程的可信性。跳过这一步等于直接拆掉了框架自带的安全屏障。

正确的修复方式 #

• 立刻补全SocialApp中的client_secret，确保和Google开发者控制台里的应用密钥完全一致。
• 切换到OAuth2授权码流程：前端请求认证URL时指定response_type=code，拿到授权码后传给后端；后端用code + client_id + client_secret调用Google的令牌接口换取access_token，同时验证该token的受众（aud字段）是否匹配你的client_id，确认未过期、未被撤销。
• 后端每次收到前端传来的token时，都要通过Google的验证接口（比如https://oauth2.googleapis.com/tokeninfo）做校验，不要直接信任解码后的内容。

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