DRF与非DRF Django跨子域联合认证实现方向咨询

这个需求完全能落地，而且你根本不需要给非DRF多页站硬套JWT，依托你现在共用Django实例、共用数据库、同根域的架构，改动量极小就能实现无缝的登录状态打通。

先把你关心的两个认知误区讲清楚 #

• 跨子域能不能传认证令牌？如果是绑定到公共根域的Cookie，完全可以正常跨子域携带；如果是存在localStorage里的JWT，因为浏览器同源策略的隔离，天然跨不了子域，硬要跨域传递反而会带来泄露风险。很多教程说的JWT跨域可用，本质也是把JWT存在同根域的Cookie里，和传统会话Cookie的传递逻辑没有任何区别。
• 非DRF场景真没必要硬接JWT：多页站是服务端渲染架构，用allauth的会话认证是最适配的方案，硬塞JWT意味着你要自己写中间件解析令牌、处理令牌过期刷新、校验逻辑，改动量比打通现有会话机制大好几倍，还容易出安全漏洞。

核心配置调整（全在共用Django实例中完成，不需要拆服务） #

所有配置只需要在settings.py中做基础调整：

• 把会话Cookie的作用域绑定到公共根域：设置SESSION_COOKIE_DOMAIN = ".你的公共根域名"，比如两个子域是site.abc.com和app.abc.com，就设为.abc.com，前缀的点代表该Cookie对所有*.abc.com的子域全局可见。
• 同步配置CSRF Cookie的作用域：设置CSRF_COOKIE_DOMAIN = ".你的公共根域名"，避免跨子域发起的POST/GraphQL请求被CSRF校验拦截。
• 安全属性适配线上环境：配合HTTPS部署设置SESSION_COOKIE_SECURE = True、CSRF_COOKIE_SECURE = True，同时设置SESSION_COOKIE_SAMESITE = "Lax"，既保证跨子域跳转时Cookie能正常携带，又符合基础安全防护要求。

双端认证打通的逻辑 #

依托同一个Django用户体系，不需要做额外的用户身份同步：

非DRF多页站点侧 #

• 不需要改动现有allauth的登录逻辑。用户通过allauth完成登录后，Django原生的认证中间件会直接生成绑定当前用户的会话ID，存在刚才配置的跨子域Cookie中，后续无论哪个子域发来的请求，只要携带这个会话ID，Django就能自动识别出对应的登录用户。

DRF+GraphQL的React应用侧 #

• 不需要废弃现有JWT认证机制，只需要在settings.py的REST_FRAMEWORK配置块中，把Django原生的rest_framework.authentication.SessionAuthentication放到JWT认证类的前面。这个认证类会自动读取跨子域Cookie中的会话ID，验证通过后直接把当前用户绑定到请求对象上，前端不需要额外手动传递令牌。
• 保留现有JWT的颁发逻辑：当用户通过会话认证访问DRF接口时，后端可以自动为当前会话的用户生成对应的JWT令牌下发给前端，供React应用后续的接口调用使用，不需要用户重新输入密码换取令牌。
• 补全反向打通逻辑：当用户在React侧通过原有JWT流程完成登录时，后端在验证账号密码通过后，主动调用Django的login(request, user)方法，生成对应的会话ID并写入跨子域Cookie。这样用户后续跳转到非DRF多页站时，多页站可以直接通过这个会话ID识别登录状态，不需要重复登录。

几个一定要避开的坑 #

• 别把JWT当跨子域传递的核心介质：如果为了传JWT把令牌拼在跳转URL参数里，很容易泄露到浏览器历史、服务端访问日志、第三方统计脚本里，安全性比会话Cookie差很多。
• 别给非DRF站单独写JWT校验逻辑：现有会话机制已经完全覆盖多页站的认证需求，硬加JWT纯粹是增加维护负担。
• 登录登出要做全链路同步：用户在任意一侧点登出时，要同时清除跨子域的会话Cookie、吊销对应的JWT令牌，不然会出现一侧已经登出，另一侧还保持登录的安全问题。

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