Next.js 14 搭配Django登录的Cookie管理方案选型疑问

问题背景 #

我在用Next.js 14搭配Django做后端，要实现用户认证功能，目前有两种Cookie管理方案：

1. 原方案：前端通过Redux和RTK Query直接调用Django API，验证通过后将access token存入前端状态，refresh token以HttpOnly Cookie形式返回；token过期时，调用refresh API刷新双令牌（全程使用HTTPS），想确认该方案是否安全。
2. 实验方案：前端表单调用服务器端Action，由Action转发请求到Django API；认证成功后提取返回的refresh token，在Next.js端设置为HttpOnly Cookie；后续刷新令牌也必须通过服务器端Action（直接用RTK Query无法将Cookie发送至Django）。

我疑惑这个实验方案是否有必要，担心会增加服务器负载（请求需经Next.js转发到Django，最终访问PostgreSQL），同时想了解使用服务器端Action的优势。

相关代码示例 #

try {
        const data = { "email": formData.get('email') as string, "password": formData.get('password') as string }
        let response:LoginMerchant = await loginAPICall(data)
        let refreshToken = response.refresh_token
        if(refreshToken){
            cookies().set('refresh', refreshToken, {sameSite:'none', secure:true, httpOnly:true})
            delete response.refresh_token
        }
        return response as LoginMerchant
    }

方案分析与解答 #

1. 原方案的安全性 #

原方案是安全的，核心依据如下：

• HttpOnly Cookie存储refresh token：这种方式能彻底避免XSS攻击窃取refresh token——前端JS无法读取HttpOnly Cookie，再加上全程HTTPS传输，可有效防止中间人攻击窃取Cookie内容。
• access token存前端状态：只要用HTTPS传输，access token在网络层面不会泄露；存在Redux内存状态中，页面刷新后会自动丢失，属于短期低风险存储，只要做好基础XSS防护（比如内容转义、配置CSP）就没问题。
• refresh token刷新流程：调用refresh API时，浏览器会自动携带HttpOnly的refresh token，Django验证通过后返回新的双令牌（自动更新Cookie），这是行业标准的安全刷新机制。

2. 实验方案的必要性与优势 #

必要性判断

如果原方案中RTK Query无法携带refresh token Cookie调用Django的refresh API，大概率是跨域配置未到位，而非方案本身有问题：

• 检查Django的CORS配置，是否允许Next.js域名，且开启了credentials: true；
• 前端RTK Query的请求配置需添加withCredentials: true，浏览器才会在跨域请求中携带Cookie。

只要跨域配置正确，原方案完全可以正常运行，实验方案并非必要。

服务器端Action的优势（若确实需要使用）

• 统一认证逻辑：把认证相关的请求逻辑集中在服务器端Action，前端无需关心API调用细节；后续修改认证规则时，只需调整服务器端代码，无需改动前端。
• 规避跨域难题：如果跨域配置因复杂域名环境难以调整，服务器端Action作为同域请求转发，可绕过浏览器的跨域限制，省去前端CORS配置的麻烦。
• 额外安全校验：可在服务器端Action中添加IP白名单、请求频率限制等额外校验，比纯前端校验更可靠。
• Cookie配置更灵活：前端设置Cookie受同源策略限制，服务器端Action可更精准地配置sameSite、domain等参数，适配不同域名场景。

负载问题的影响

实验方案确实会增加Next.js服务器的负载，因为每个认证请求多了一层转发。但如果用户量在几万级以下，这种额外负载几乎可以忽略；若用户量较大，可在Next.js层添加缓存（比如缓存refresh token的有效状态），或调整架构减少转发请求的频率。

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