개발자
안녕하세요 NextJS14 에서 JWT 로그인 방식으로 프로젝트 진행중에 있습니다. 현재 AccessToken 만료시 재 갱신하는 로직을 하면서 해결하지 못하는 내용이 있어서 문의 드리립니다. 서버 컴포넌트와 클라이언트 컴포넌트에서 갱신된 AccessToken 을 공유 하는 법에 대해서 어떻게 처리 하셨나요? - app router 사용 - accessToken, refreshToken 쿠키 사용 - fetch 를 이용하여 API 호출 아래 테스트 내용으로 서버 컴포넌트에서 AccessToken 만료되어 갱신되는 경우 클라이언트로 쿠키를 갱신해줄 방법을 모르겠습니다. 너무 CSR 구조로 생각하는거 같기도해서, 이런 경우 어떻게 토큰을 현행화 해서 사용하는지 문의 드립니다. 별도 가이드 문서를 더 찾아보면 서버 컴포넌트에서는 쿠키를 사용하지 말라는 글도 보여서, 방향성을 잘못잡고 있는 느낌도 들고 있습니다. 많은 조언 부탁드립니다!! 테스트 케이스) 1. 서버 <-> 클라이언트 (에러) - 서버 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출 -> 쿠키 set -> 클라이언트에서 백엔드 API 호출(당연히 클라이언트에서는 쿠키가 갱신안되서 에러) 2. 서버 <-> 서버(성공) - 서버 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출-> 쿠키 set -> 서버 백엔드 API 호출 3. 클라이언트 <-> 클라이언트 (성공) - 클라이언트 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출-> 쿠키 set -> 클라이언트 백엔드 API 호출
답변 1
next가 클라이언트(브라우저)와 통신할 수 있는 기회는 현재로서는 2가지 경로입니다. 1. middleware 2. route handler 이 둘 모두 첫번째 파라미터인 request 객체를 통해 쿠키를 조회할 수 있고, cookies 모듈을 통해서도 조회/설정할 수 있습니다. 이 모듈은 서버 컴포넌트에서도 사용할 수 있지만 조회만 가능합니다. 그래서 테스트 케이스 2번의 경우 "쿠키 set"에서 밀어넣은 토큰 정보가 브라우저에서 확인해보면 보이지 않을겁니다. middleware는 페이지를 로드하기 이전에 next 서버에서 가장 먼저 읽는 파일입니다. 따라서 앱의 모든 위치에서 페이지 로딩 전 해야할 공통 작업이 있다면 여기서 처리할 수 있습니다. middleware에서 request 객체를 조회하면 클라이언트의 요청 헤더를 통해 쿠키를 조회할 수 있고, cookies 모듈이나 response 객체를 통해서 쿠키를 설정할 수도 있습니다. 그래서 보통 이 영역에서 토큰을 체크하고 갱신합니다. 지금의 middleware는 요청도 만들어서 보낼 수 있고, 대기도 가능하고, 후처리도 할 수 있습니다. 토큰의 가부 혹은 만료 여부를 판단해 새로운 토큰을 받아 갱신하고, 이 과정 상에 에러가 생긴다면 리디렉션을 실행합니다. route handler에서도 동일하게 request와 response, cookies 모듈을 사용할 수 있습니다. 그러나 페이지가 이미 로딩이 된 이후이므로 도메인의 보호가 불완전합니다. 그래서 보통 middleware를 사용합니다. 단, crud에 의한, 그러니까 사용자에 의한 api호출 시에도 access token의 체크가 필요하고, 갱신까지 필요하다면 보다 복잡한 패턴이 요구됩니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 09월 02일
Next.js 14에서는 서버 컴포넌트를 도입하여 클라이언트와 서버 사이의 데이터 공유 기능에 대하여 제한이 있습니다. 이 문제를 해결하기 위해서는 클라이언트와 서버 간에 상태(state) 관리 및 토큰 관리 방식에 대한 작업을 재구성해야 할 수 있습니다. 서버 컴포넌트가 아닌 경우, 쿠키나 로컬 스토리지를 사용하여 JWT 토큰을 저장하고 이용하는 것이 일반적입니다. 하지만, 서버 컴포넌트에서는 이전과 같은 접근 방식이 작동하지 않으므로 다른 해결책을 찾아야 합니다. Next.js는 HTTP Only 쿠키를 사용하여 서버와 클라이언트 사이에서 안전하게 JWT 토큰을 주고 받을 수 있습니다. 따라서, HTTP Only 쿠키를 사용하여 JWT의 access token과 refresh token을 저장하고, 두 토큰 모두를 액세스 할 수 있는 중앙 저장소 (Central Store) 을 사용하는 것입니다. 이렇게 하면 API 호출 시 유저 인증에 필요한 토큰 정보를 항상 최신 상태로 유지할 수 있어 보안성도 유지됩니다. 로그인 시 AccessToken과 RefreshToken을 받아오면 쿠키에 저장하고, API 호출 중 AccessToken이 만료되면 RefreshToken을 이용하여 AccessToken을 갱신하고 다시 쿠키에 저장하는 방식으로 해결할 수 있습니다. 이러한 방법은 서버와 클라이언트 코드 모두에서 사용 가능하며, 프론트엔드 및 백엔드 코드 작성 시 일관성도 제공합니다. 하지만 새로운 아키텍쳐를 도입하기 위해선 기존 코드의 대부분을 리팩토링 할 필요가 있으므로 각각의 프로젝트 상황에 맞게 적절한 결정을 내려야합니다. 또한 Next.js서버 컴포넌트는 아직 실험적인 기능이므로, 이를 고려하여 토큰 관리 전략을 수립하는 것도 중요합니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!