Next.js server component(app router)의 auth 관련 질문 입니다.

Question

안녕하세요. 이번에 Next.js(13)에서 최신 기술인 app router를 기반으로 자그마한 홈페이지를 구축 중에 있습니다. JWT 기반으로 SSR을 구축하고 있습니다. middlware로 어떻게 든 토큰 재발행이 가능한 로그인 구현을 완료 했습니다. 하지만 ServerComponent이다 보니, RSC에서 accesstoken 혹은 refreshtoken과 같은 인증 토큰이 만료 되었을 때, 재 발행을 하려면 어떻게 해야 할까요? cookie나 header는 접근은 가능해도 Set-Cookie를 내려 보내거나 할 수는 없는 걸로 문서에 나오고 실제로도 되지 않습니다. 어떻게 하면 ServerComponent에서 토큰을 재발행 하거나 다른 인증 방법이 있을 까요? 아니면 JWT + Session으로 가는 조합을 사용 해야 할까요??? 또, client와 server 간의 토큰 공유를 위해 access-token만 http-only를 해제하고 사용 중에 있습니다. 이게 cors나 csrf와 같은 공격에 취약한 문제가 있어서 이게 올바른 구현 방법일까요? 일단 제가 찾은 방법으로 가장 쉽게 해결되는 방법은 아직 실험 단계인 server action을 활성화 해서 클라이언트에서 토큰을 가지고 있을 필요가 없이 서버에서만 관리 하는 방법입니다. BFF을 일부 수용해서 해결 했습니다. front <-> BFF <-> api

Ed · Answer

저도 궁금해서 그러는데 혹시 클라이언트 컴포넌트로 안하는 이유가 굳이 있나요? 로그인 관련은 유저로부터 정보를 받아야 하니 서버컴포넌트로는 불가능하지 않나요.? 저도 최근에야 13을 공부하는 중이라 확실히는 모르셌네요..

김태우 · Answer

저도 프로젝트 중에 이 문제를 만났었는데 저는 페이지 자체는 ssr로 하되 로그인 요청 부분을 컴포넌트로 분리시켜 use client를 사용하고 서버에서 쿠키에 저장했었습니다.

근데 말씀하신 것 중에 궁금한 점이 로그인 페이지는 서버로부터 받아올 데이터가 없기 때문에 ssr로 하나 csr로 하나 차이가 없는 것으로 알고 있습니다.

따라서 Next에서는 빌드시에 자동으로 정적 생성(SSG)해두는 것으로 알고 있어 성능 차이가 없는 것으로 알고 있는데 아닌가요..?

Next 배포 처리 방식이 조금 특이해서 알아봤었는데 서버 컴포넌트를 사용한다고 해서 ssr되는 것이 아니었더라구요.

(수정) 정적 생성이 아니라 pre-render요!

관련 문서입니다.
https://nextjs.org/learn-pages-router/basics/data-fetching/pre-rendering
Next.js는 기본적으로 모든 페이지에 프리 렌더링이 적용된다고 합니다.

상현 · Answer

그걸 하라고 있는 게 route handler와 server action 이라고 보지만 - BFF 계층이 있는 곳이라면 저 영역이 그곳 - , 안정적이지 않습니다. 정확히는 next가 만들어 둔 구성 요소들이 서로 상충한다고 봅니다.

RCC에서 server action을 호출하고 그 로직 안에서 next/cookies 모듈을 이용하면 에러가 발생합니다. 이 모듈은 RSC 전용이죠.

route handler도 RCC에서 호출해야 request의 주체가 클라이언트(user agent)가 되기에 쿠키 정보를 조회/설정할 수 있고, 서버에서 호출한 경우에는 조회/설정이 불가능합니다.

현재 유일하게 신뢰할 수 있는 서버-클라이언트 간 쿠키 조회/설정은 middleware 뿐입니다.

문제는 여기는 통신 중의 탈취 공간이라 또 다른 요청을 만들 수가 없단 점이고요.

도메인 기반의 msa 서비스를 구성 중인 곳은 app router를 사용하는 게 태생적으로 어려운 이유이죠. 제 생각엔 과거로의 회귀가 맞다고 봅니다. next/auth도 credentials 방식 (Id, password 정보를 들고가서 인증)이 주 타켓입니다.