next-auth中从API获取的JWT token应当如何存储以用于后续接口请求？

首先明确结论：两个你提到的方案都不需要，你只需要调整现有的jwt回调逻辑即可，next-auth会自动帮你把自定义字段存储到自带的安全HttpOnly Cookie中。 #

问题根因 #

你当前的jwt回调仅处理了user.type和user.username两个字段，但你后端返回的user对象只有token字段，所以没有任何自定义字段被写入next-auth管理的JWT中，最终你在session回调中拿到的就是仅包含默认签发时间(iat)和过期时间(exp)的token对象。 #

具体修改步骤 #

1. 修改jwt回调，存储自定义token #

当用户首次完成授权时，authorize返回的user对象会作为参数传入jwt回调，此时你只需要将后端返回的token写入next-auth的JWT对象即可，后续next-auth会自动将这个完整的JWT加密后存储到HttpOnly Cookie中，无需你手动操作Cookie。
修改后的jwt回调示例：

async jwt(token, user, account, profile, isNewUser) {
  // 仅首次授权时user参数有值，后续刷新JWT时不会携带user
  if (user) {
    // 把后端返回的自定义token存入next-auth的JWT
    token.accessToken = user.token
    // 你原来的逻辑也可以保留，如果后续有相关字段的话
    if (user?.type) {
      token.status = user.type
    }
    if (user?.username) {
      token.username = user.username;
    }
  }
  return token
}

2. 根据使用场景选择是否暴露给前端 #

• 如果你是在服务端调用API，可以直接从next-auth的JWT中取出accessToken使用，不需要暴露给前端。
• 如果你需要在前端调用API时使用这个token，可以在session回调中将accessToken挂载到session对象返回给前端：

async session(session, token) {
  session.accessToken = token.accessToken
  session.type = token.type;
  session.username = token.username;
  return session
}

为什么不推荐你提到的两个方案 #

• 不要手动在session回调中设置HttpOnly Cookie：next-auth本身已经维护了一套加密的HttpOnly Cookie存储逻辑，手动新增Cookie不仅会增加安全风险，还可能和next-auth的会话管理逻辑冲突。
• 不要在authorize方法中处理存储逻辑：authorize的职责仅为验证用户凭证并返回用户信息，存储属于会话管理的逻辑，放到jwt回调中处理更符合next-auth的设计规范，也更易维护。

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