커스텀 인증에서 NextAuth 기반 JWT 체계로 전환

문제 상황

• 프로젝트 초기에 로그인·회원가입 로직을 직접 구현하고 세션 스토리지를 사용했으나, 저장소 노출 위험(CSS), 토큰 수명/갱신 관리 등의 보안 취약점이 드러남.
• 유지보수성과 확장성(소셜 로그인 연동, 서버 사이드 보호 등) 측면에서도 한계가 있어 개선이 필요했음.

환경

• 프로젝트: 웹 애플리케이션 인증 전환
• 스택: Next.js, TypeScript, NextAuth
• 외부 연동: Google OAuth(추가 소셜 로그인 확장 가능)

증상/로그

증상: 세션 스토리지에 민감 정보 저장, 토큰 만료/갱신 수동 관리, SSR 보호 미흡
로그: 명시적 에러는 적으나 인증 흐름의 일관성/보안성 부족으로 운용 리스크 존재

원인 분석

• 브라우저 저장소(sessionStorage/localStorage) 기반 인증은 XSS 시 노출 위험이 존재.
• 커스텀 로직은 토큰 로테이션/만료 처리/CSRF 대비/서버 사이드 보호를 일관적으로 커버하기 어려움.
• 소셜 로그인(예: Google) 통합 시 표준 프로토콜과의 세부 차이를 직접 관리해야 하는 부담이 큼.

해결 방법

1. NextAuth 도입 결정 및 학습
   • 공식 문서 기반으로 세션 전략, JWT 전략, 콜백 구조(session/jwt/signIn) 이해.
2. JWT 전략 채택
   • session: { strategy: 'jwt' }로 설정하고, 토큰에 필요한 클레임(roles, id 등)을 jwt/session 콜백에서 안전하게 주입.
3. 프로바이더 통합
   • Google OAuth 프로바이더를 추가하고 기존 커스텀 로그인 흐름은 NextAuth의 인증 엔드포인트로 이관.
   • 필요 시 Credentials Provider로 기존 폼 로그인도 흡수(서버에서 비밀번호 검증 후 JWT 생성/병합).
4. 보호 구간 정리
   • 미들웨어 또는 서버 액션/라우트 핸들러에서 auth()/getServerSession()으로 보호, 클라이언트는 useSession()으로 상태 관리.
5. 데이터/권한 모델 정리
   • 사용자 스키마와 역할/권한을 표준화하고, JWT에 최소 정보만 포함. 서버에서 추가 검증 수행.

검증

• 로그인/로그아웃/토큰 갱신 흐름, 보호 라우트 접근 제어, SSR 페이지에서의 세션 인입 검증.
• Google OAuth 로그인, 기존 사용자와의 매핑, 실패/취소 플로우 처리 확인.

배운 점

• 인증은 표준화된 라이브러리를 활용하면 보안·유지보수·확장성 모두를 개선할 수 있음.
• JWT/세션 전략과 콜백 설계를 일찍 확정하면 이후 권한 모델과 라우팅 보호가 단순해짐.
• 소셜 로그인 통합은 사용자 편의성과 진입 장벽을 낮추며, 운영 비용을 줄여줌.

참고

• NextAuth 공식 문서(구성/콜백/프로바이더)