oauth2中session由服务端管理，前端不直接操作；授权回调时服务端用code换取用户标识并存入session，后续请求靠浏览器自动携带cookie维持登录态，需配合redis等共享存储实现分布式环境下的session一致性。
JavaScript 本身不直接管理 Session，Session 是服务端机制。所谓“JavaScript 中 Session 配合 OAuth2”，实际是指前端配合后端完成 OAuth2 授权流程，并依赖服务端通过 Session 维持用户登录态。关键不在前端操作 Session，而在于前后端如何协同让 Session 正确绑定 OAuth2 获取的用户身份。
OAuth2 回调阶段：服务端用 code 换 openid 并写入 Session
用户点击微信、GitHub 或 SoundCloud 等第三方登录后，浏览器跳转到你的后端回调地址（如 /auth/callback）。此时：
- 服务端收到微信或 OAuth 提供商返回的 code，立即向其 token 接口发起请求，换取 access_token 和用户唯一标识（如 openid 或 user_id）
- 验证 code 有效性，防止重放攻击
- 调用 express-session（Express）或类似中间件，将用户标识存入当前会话：
req.session.userId = user.id; 或 req.session.openid = openid; - 同时设置安全 Cookie（httpOnly=true, secure=true, sameSite=strict），确保浏览器自动携带 session ID
后续请求阶段：浏览器自动带 Cookie，服务端校验 Session
用户完成授权后，浏览器已持有包含 session ID 的 Cookie。之后所有同域请求（如 /api/profile）都会自动带上该 Cookie：
- 服务端中间件自动解析 Cookie，还原 req.session 对象
- 接口逻辑直接从 req.session.userId 或 req.session.openid 获取身份，无需前端额外传参
- 若 Session 过期、丢失或未找到对应用户，统一返回 401 或重定向至授权页
- 避免前端用 localStorage 存 openid 后手动拼在 header 里——这绕过 Session 保护，易被篡改
生产环境必须用外部存储替代内存 Session
默认内存存储只适合单进程开发，上线后必须切换为 Redis 等共享存储：
- 安装 connect-redis（Express）或 koa-redis（Koa）
- 初始化 session 中间件时传入 Redis Store 实例，确保多实例能读写同一份 Session 数据
- 设置合理过期时间，例如 maxAge: 7 * 24 * 60 * 60 * 1000（7 天）
- Redis 还支持主动销毁（如用户登出时 req.session.destroy()），比内存更可控
注意和 JWT、前端 Token 方案的区别
Session + OAuth2 是服务端会话模式，和纯前端 JWT 方案有本质不同：
- Session 数据存在服务端，敏感信息（如用户权限、角色）可安全存放，不暴露给前端
- 登出、踢人、权限变更可即时生效（删 Redis 中对应 key 即可）
- JWT 则把用户信息签发后交由前端存储并每次携带，服务端只做签名验证，无法主动失效（除非加黑名单或缩短有效期）
- 两者不互斥：也可在 Session 建立后，服务端签发一个短期 JWT 用于 API 调用，兼顾灵活性与可控性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
