개발자
Next.js app router에서 쿠키로 JWT로그인을 사용 하고 있습니다. 서버는 백엔드 api 서버가 별도로 존재하는 상황입니다. 현재 인증 기반 api를 호출을 할 때, 만약 해당 accessToken이 만료가 됐다면 재발급을 해주는 백엔드 api를 통해 새로운 accessToken을 브라우저에 업데이트하는 로직을 구현하려고 했습니다. 클라이언트 컴포넌트에서는 전혀 문제가 없었습니다. 어차피 set-cookie를 백엔드에서 해주면 알아서 브라우저에 반영이 되니까요. 근데 문제는 서버 컴포넌트에서 동일한 요청을 하는 경우입니다. 동일하게 재발급 요청을 보낸 다음 set-cookie를 백엔드에서 해줘도 어차피 서버 컴포넌트에서 api를 쐈던것이기 때문에 그 반환값이 서버 컴포넌트로 오게 되고, 이는 브라우저에 반영이 안 되는데요ㅠ 혹시 이럴 경우에는 어떻게 처리를 하는게 좋을까요? 미들웨어나 라우트 핸들러를 사용하려 해도 그 방법을 도저히 모르겠네요
답변 1
지금 시점에서는 이미 구현하셨으리라 보지만, 알고 있는 몇가지를 적어봅니다. 1. middleware middleware는 브라우저(client)의 페이지 요청을 프론트 서버인 next.js에서 받는 중간 과정에 놓여있습니다. 이를 edge runtime이라는 이름으로도 부릅니다. 이 미들웨어의 기본 모듈은 브라우저의 요청 해더를 조회할 수 있고, 이 해더 안의 cookie 객체를 이용하면 쿠키를 조회나 설정할 수 있습니다. 2. client component + route handler server component에서 발급받은 jwt를 props를 통해 client component로 넘기고, 여기서 route handler를 호출하고 route handler에서 next의 cookies 모듈을 쓰거나 응답 해더에서 직접 설정하는 방법이 있습니다. 3. store 저장소를 쿠키가 아닌 메모리로 바꾸어, server component에서 발급받은 jwt를 context api나 상태 관리 라이브러리를 이용해서 store에 저장하고 이 provider를 root에 두어 내리는 방법이 있습니다. 다만 이 경우 쿠키와 달리 secure나 httpOnly를 걸 수 없고 react dev tools와 같은 브라우저의 확장 도구를 통해 들여다 볼 수 있어서 보안 상의 이슈가 있을 수 있습니다. 보통 라우트 보호는 1의 방법을 사용하지만, crud 요청에서 unauthorized가 발생해 jwt를 재발급하는 과정이 필요한 때는 1로는 해결할 수 없습니다. 요청이 실패했다고 하여 페이지를 새로고침할 수는 없으므로... 그래서 통합 관리를 생각하면, 라우트 보호는 middleware에서 refresh token을 조회하여 그 사용 가부를 확인만 하는데 그치고, access token은 2 또는 3의 방법을 사용하되, 재사용 가능한 방식으로 구조화하는 것이 좋습니다. 또 access token의 유효기간에 따라서도 방법이 갈릴 수 있으니 여러 방식에서 테스트하며 상황에 맞는 방법을 찾는 것을 권장드립니다. app router에서 jwt 제어는 생각보다 손이 꽤 많이 갑니다.
익명
작성자
1월 31일
안녕하세요! 꽤 많은 시간이 지났음에도 이렇게 친절히 지식을 공유해주셔서 정말 감사합니다 :)
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!