NextAuth+OneLogin场景下NodeJS+Express API认证实现咨询

架构调整核心思路 #

现有Vercel Serverless场景下Mongo连接数超限的核心原因是无服务函数冷启动无法复用连接，哪怕是NextAuth查会话的请求都会新建连接，因此把所有数据库交互收拢到长驻运行的Express服务是正确方向，认证逻辑不需要绑定NextAuth内部实现，基于标准JWT做跨服务鉴权即可，同时天然兼容后续React Native端。

一、Next.js侧NextAuth配置调整 #

• 保留NextAuth对接OneLogin的OIDC登录回调流程，不需要把登录入口迁移到Express服务，减少现有业务改动量
• 把NextAuth会话策略从默认的database改为jwt，移除直连Mongo的NextAuth数据库适配器，不再将会话写入数据库，从源头上减少Vercel侧直连Mongo的请求量
• 统一配置NEXTAUTH_SECRET作为JWT签名密钥，该密钥后续同步给Express服务使用；在jwt回调中按需写入用户ID、角色、权限版本号等必要字段，不要放敏感信息
• NextAuth的session回调仅做前端会话读取，不触发任何数据库查询，所有用户数据、业务数据的拉取全部走独立Express API接口
• 调整session cookie配置：如果Next服务和Express服务部署在同一根域名下，把cookie的domain设置为根域名，sameSite设为lax，跨域名部署则设为none并开启secure，让API服务可以直接读取到请求带的会话cookie

不要担心JWT无法主动作废的问题：后续如果需要做登出踢人、权限实时生效，只需要在Mongo里存每个用户的当前token版本号，JWT中携带版本字段，鉴权时比对版本即可，性能损耗远低于每次查会话表。

二、Express服务侧认证实现 #

Express服务为长驻进程，启动时初始化全局复用的Mongo连接池即可彻底解决连接数超限问题，认证逻辑独立实现，无需依赖NextAuth相关依赖包：

• 服务启动阶段初始化Mongo连接池，根据Mongo Atlas集群规格配置合理的最大连接数（M0免费集群配20-30连接数足够支撑千级QPS），全局缓存连接实例，所有接口复用该连接，避免重复建连
• 编写全局认证中间件，核心逻辑：
  1. 优先从Authorization: Bearer <token>请求头提取token，兼容从next-auth.session-token cookie中读取token，覆盖Web端、移动端的不同传参场景
  2. 使用和NextAuth侧一致的NEXTAUTH_SECRET校验JWT签名、过期时间，验签失败直接返回401状态码
  3. 验签通过后解析JWT中的用户唯一标识（对应OneLogin返回的sub字段），可按需查询Mongo校验用户状态（是否封禁、权限是否变更），校验通过后把用户信息挂载到req.user上传递给后续业务接口
• 所有需要鉴权的业务路由统一挂载该中间件，公开路由直接放行

认证中间件核心代码参考：

const jwt = require('jsonwebtoken');
const { getMongoClient } = require('./db'); // 全局缓存的Mongo连接实例

async function authGuard(req, res, next) {
  // 兼容头传参和cookie传参
  const token = req.headers.authorization?.replace('Bearer ', '') 
    || req.cookies['next-auth.session-token'];
  if (!token) return res.status(401).send({ code: 401, message: '未授权访问' });

  try {
    const tokenPayload = jwt.verify(token, process.env.NEXTAUTH_SECRET);
    const db = getMongoClient().db();
    // 按需查询用户状态，不需要的场景可以跳过这步直接用payload里的信息
    const user = await db.collection('users').findOne(
      { oneLoginId: tokenPayload.sub },
      { projection: { hashPassword: 0, sensitiveInfo: 0 } }
    );
    if (!user || user.isBanned) return res.status(403).send({ code: 403, message: '无访问权限' });
    req.currentUser = user;
    next();
  } catch (err) {
    return res.status(401).send({ code: 401, message: '登录态已失效' });
  }
}

module.exports = authGuard;

三、React Native移动端适配方案 #

该架构不需要为移动端单独开发认证逻辑，直接复用现有鉴权体系：

• 移动端对接OneLogin的PKCE授权码模式完成OIDC登录流程，拿到和Web侧结构、签名规则一致的JWT
• 移动端发起API请求时，统一把JWT放在Authorization请求头中，和Web侧走完全相同的鉴权逻辑，不需要额外适配
• 移动端的登出、token刷新逻辑和Web侧保持规则一致即可

四、上线注意事项 #

• 两侧服务配置正确的CORS规则，仅放行可信前端域名，避免跨域问题
• JWT有效期和OneLogin侧的token有效期对齐，避免出现OneLogin侧已失效但JWT仍可用的时间差
• Express服务侧配置Mongo连接池的闲置超时时间，及时释放闲置连接，避免占用Atlas连接配额
• 必要时在鉴权逻辑中加短缓存（比如1分钟的用户信息本地缓存），进一步降低Mongo查询压力

内容的提问来源于stack exchange，提问作者Akhilesh B Chandran