React+Node.js+Passport-Google-OAuth2开发环境Cookie存储问题咨询

我之前也碰到过一模一样的场景——Webpack Dev Server和Node后端分开跑，Google OAuth认证后Cookie死活存不下来，折腾了好一阵才搞定。下面给你拆解问题原因和最佳实践：

一、先搞清楚为什么Cookie存不住 #

核心问题是跨域+代理配置不到位：

• 前端跑在localhost:3000，后端在localhost:3001，属于不同端口，浏览器会判定为跨域请求
• 即使配置了代理，如果没处理Cookie的域名重写、请求头Origin，后端返回的Cookie会被浏览器直接拦截

二、分步解决Cookie保存问题 #

1. 正确配置Webpack Dev Server代理 #

你的代理没生效大概率是参数没配全。在webpack.config.js的devServer.proxy里，必须加上changeOrigin和cookieDomainRewrite：

module.exports = {
  // ...其他Webpack配置
  devServer: {
    proxy: {
      '/api': { // 匹配所有API请求路径
        target: 'http://localhost:3001', // 你的Node后端地址
        changeOrigin: true, // 关键：让后端收到的请求Host变成target地址，避免跨域拦截
        cookieDomainRewrite: 'localhost', // 把后端设置的Cookie域名重写为前端的localhost
        secure: false, // 开发环境是HTTP，设为false
      },
      '/auth': { // OAuth相关路径也要走代理
        target: 'http://localhost:3001',
        changeOrigin: true,
        cookieDomainRewrite: 'localhost',
        secure: false,
      }
    }
  }
};

注意：OAuth的回调路径（比如/auth/google/callback）也必须走代理，不能直接指向后端地址，否则回调后的Cookie还是会绑定到后端端口，浏览器不会识别。

2. 后端调整Cookie的属性设置 #

用Passport+Express的时候，Cookie的属性直接决定浏览器会不会保存它。在配置session或Cookie时，要根据环境动态调整：

// Express session配置（如果用session存用户信息）
app.use(session({
  secret: 'your-strong-secret-key',
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: process.env.NODE_ENV === 'production', // 开发环境设为false（HTTP不支持secure Cookie）
    sameSite: process.env.NODE_ENV === 'production' ? 'none' : 'lax', // 开发环境用lax即可
    httpOnly: true, // 保留这个，防止XSS攻击
    maxAge: 24 * 60 * 60 * 1000, // Cookie有效期1天
    path: '/' // 确保全站都能访问到Cookie
  }
}));

如果是直接设置Cookie（不用session），也要遵循同样的属性规则。

3. 核对Google OAuth的回调地址 #

去Google Cloud Console的OAuth 2.0客户端ID设置里，把回调地址改成前端代理后的地址，比如：
http://localhost:3000/auth/google/callback
而不是后端的http://localhost:3001/auth/google/callback。这样OAuth回调完成后，请求会回到前端服务器，Cookie才能正确绑定到localhost域名。

三、要不要放弃用Cookie？ #

完全没必要！Cookie在生产环境是非常可靠的认证方案：

• 配合httpOnly、secure、sameSite属性，安全性很高，能避免XSS攻击
• 服务器端可以主动失效session（比如用户登出时销毁session），比JWT更灵活

如果实在不想用Cookie，也可以改用JWT：把token存在前端的localStorage或sessionStorage里，每次请求通过Authorization: Bearer <token>头传给后端。但JWT有个明显缺点——无法主动失效token（除非维护黑名单），而且存在localStorage有XSS风险，不如httpOnly Cookie安全。

所以优先解决开发环境的Cookie问题，而不是直接替换方案。

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