Next.js에서 토큰 전략 제대로 이해하고 설계하기

Next.js 앱에서 토큰이 필요한 이유

Next.js는 SSR(Server-Side Rendering), CSR(Client-Side Rendering), API Routes 등 다양한 렌더링 방식을 혼합할 수 있어요.
이 말은 인증 정보(토큰)가 클라이언트와 서버 모두에서 필요할 수 있다는 뜻이죠.

• 클라이언트 측 페이지 전환 시에도 사용자 상태 유지
• 서버 측에서 SSR 할 때도 로그인된 사용자 정보 필요
• API Routes 보호

즉, 토큰 전략을 제대로 세워야 모든 렌더링 방식에서 일관되게 인증이 유지됩니다.

 

Next.js에서 주로 쓰는 토큰 전략

HttpOnly 쿠키

• 서버에서 응답할 때 쿠키에 토큰을 심음
• 클라이언트 JS에서는 접근 불가능 (XSS 안전)
• 자동으로 요청에 쿠키가 포함돼서 SSR에서 인증 확인이 쉬움

✅ 장점

• 보안성 ↑ (HttpOnly, Secure 옵션)
• SSR + CSR 모두 자연스럽게 토큰 유지

✅ 단점

• CSRF 공격에 주의 (SameSite 설정 필요)
• 설정이 살짝 번거로움

LocalStorage

• 클라이언트가 토큰을 로컬스토리지에 저장

✅ 장점

• 구현 매우 간단
• SPA에서 상태 유지 쉽다

✅ 단점

• XSS 취약
• SSR에서 토큰 접근 불가능

세션 기반 (NextAuth.js)

• 서버가 세션을 쿠키로 관리
• JWT나 데이터베이스 기반 세션 저장
• NextAuth.js 같은 라이브러리가 이 과정을 자동으로 처리

✅ 장점

• SSR, API Routes에서도 세션 정보 바로 접근
• 구현 편리

✅ 단점

• 라이브러리 의존성
• 서버 환경 설정 필요

Next.js에서 추천하는 전략

Next.js에서 권장하는 방식은 HttpOnly 쿠키를 통한 토큰 관리입니다.
왜냐하면:

• SSR 시 getServerSideProps에서 쿠키를 읽어 사용자 인증 상태를 전달할 수 있음
• 클라이언트 사이드도 쿠키로 자동 인증
• HttpOnly 설정으로 XSS로부터 안전

실전 설계 예시

➜ 액세스 토큰 + 리프레시 토큰 전략

• 액세스 토큰은 유효기간 짧게 (예: 15분)
• 리프레시 토큰은 HttpOnly 쿠키에 저장 (만료 길게)
• 액세스 토큰 만료 시, 서버에서 쿠키의 리프레시 토큰으로 새 토큰 발급

✅ 장점

• 보안 + 사용자 경험 모두 만족
• 클라이언트는 액세스 토큰 갱신 요청만 하면 됨

NextAuth.js로 구현 예

NextAuth.js는 이 전략을 매우 쉽게 지원합니다.

• JWT 기반 세션: 서버리스 환경에서도 stateless
• Database 기반 세션: 서버 상태 저장 가능
• 쿠키 옵션 커스터마이즈 가능

session: {
  strategy: "jwt",
  maxAge: 30 * 60, // 30분
},
jwt: {
  secret: process.env.JWT_SECRET,
  maxAge: 30 * 60,
},

 

서버사이드에서 토큰 사용 예

export async function getServerSideProps(context) {
  const session = await getServerSession(context.req, context.res, authOptions);

  if (!session) {
    return {
      redirect: { destination: "/login", permanent: false },
    };
  }

  return {
    props: { user: session.user },
  };
}

 

SSR에서 바로 세션 확인 → 페이지 보호!