NestJS+GraphQL+Next.js鉴权实现：能否使用next-auth？

你已经有一套成熟的Nest.js GraphQL鉴权体系（Access/Refresh Token），next-auth反而会给你增加不必要的配置复杂度——它的核心优势是快速对接第三方登录、简化无自定义鉴权后端的场景，完全没必要套在你的现有架构上。直接基于自己的鉴权API做轻量集成更高效，具体可以这么搞：

1. 客户端登录逻辑 #

• 在Next.js的登录组件里，直接调用Nest.js的GraphQL登录mutation，传入账号密码，拿到返回的Access Token和Refresh Token。
• 存储策略：
  • Access Token可以存在localStorage（方便客户端请求时读取），但要注意XSS风险，也可以让Nest.js返回时设置成HttpOnly + Secure的Cookie（需要配置跨域Cookie支持）。
  • Refresh Token必须存在HttpOnly Cookie里，由Nest.js在登录接口响应时通过Set-Cookie头设置，避免前端脚本篡改。
• 登录成功后直接跳转到目标页面即可。

2. 封装GraphQL请求客户端（以Apollo Client为例） #

• 配置Apollo Client时，添加请求拦截器，自动在每个请求头里带上Authorization: Bearer ${accessToken}。
• 添加响应拦截器：如果收到401（Token过期），自动调用Nest.js的刷新Token接口，用Cookie里的Refresh Token换取新的Access Token，更新本地存储后重新发起原请求；如果刷新失败（比如Refresh Token也过期），直接跳转到登录页并清除无效Token。

示例代码片段：

import { ApolloClient, createHttpLink, InMemoryCache } from '@apollo/client';
import { setContext } from '@apollo/client/link/context';
import { onError } from '@apollo/client/link/error';

const httpLink = createHttpLink({
  uri: '你的Nest.js GraphQL接口地址',
});

const authLink = setContext((_, { headers }) => {
  const accessToken = localStorage.getItem('accessToken');
  return {
    headers: {
      ...headers,
      authorization: accessToken ? `Bearer ${accessToken}` : '',
    },
  };
});

// 处理Token刷新的链路
const errorLink = onError(({ graphQLErrors, operation, forward }) => {
  if (graphQLErrors?.some(err => err.extensions?.code === 'UNAUTHENTICATED')) {
    // 调用刷新Token的mutation
    return refreshToken().then((newToken) => {
      localStorage.setItem('accessToken', newToken);
      // 更新请求头并重发
      operation.setContext(({ headers = {} }) => ({
        headers: {
          ...headers,
          authorization: `Bearer ${newToken}`,
        },
      }));
      return forward(operation);
    }).catch(() => {
      // 刷新失败，跳登录
      window.location.href = '/login';
    });
  }
});

const client = new ApolloClient({
  link: errorLink.concat(authLink.concat(httpLink)),
  cache: new InMemoryCache(),
});

3. 页面权限控制（兼顾SEO） #

因为你用Next.js是为了SEO，页面大概率是SSG或SSR：

• SSR页面（getServerSideProps）：在服务端从请求的Cookie里取出Refresh Token，调用Nest.js的验证接口（或直接解析Token），验证通过再获取页面数据；验证失败则重定向到登录页。
• SSG页面：静态内容直接生成（保证SEO），客户端渲染时先检查本地的Access Token，无效则跳登录，有效再渲染动态内容。

4. 登出逻辑 #

• 调用Nest.js的登出接口（如果后端需要销毁Refresh Token），然后清除本地的Access Token，同时让后端清除Refresh Token的Cookie，最后跳转到登录页。

为什么不用next-auth？ #

next-auth需要你自定义provider来适配现有JWT体系，还要配置session管理、Token刷新逻辑，反而会和你现有Nest.js的鉴权链路冲突，增加不必要的学习和维护成本。你已经有完整的鉴权闭环，自己实现的方案更轻量、更贴合你的架构。

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