개발자
nextJS 에서 안전하게 token 처리하기
nextjs에서 nextAuth 쓰지않고 안전하게 token 처리하는 완벽한 예시가 있는지 알고싶습니다. 사이드 프로젝트중에 여러 시도를 해봤는데 정답을 못찾겠습니다. 일단 axios 인터셉트로 ssr이나 csr이나 모두 토큰을 헤더에 담아서 보내는 것을 목표로 하고 있습니다. 1. 상태관리 라이브러리를 사용한다. 당연히 ssr 환경에서는 불가하니 탈락 2. 그냥 쿠키를 사용한다 보안 문제가 있으니 탈락. 3. http only 쿠키를 사용한다. csr 환경에서 접근할 수 없으니 탈락. 대안으로 생각해본 방법들은 1. 모든 api를 server action을 랩핑해서 미들웨어처럼 사용하고 http only 쿠키 이용하기 2. 쿠키와 상태관리 모두 값을 넣어두고 두가지 다 관리하면서 서버와 클라이언트 컴포넌트에서 각각 제어하기 하지만 두가지 방법은 너무 번거롭고 버그 양산일 것 같습니다. 많은 분들께 여쭤봤을 때는 그냥 쿠키를 사용하고 보안은 어느정도 포기한다는데 다른 방법이 있을까요?
답변 1
안녕하세요 답변 드립니다. 😏 역설적으로 2번의 쿠키 사용 탈락의 이유로 보안을 예시로 말씀 주셨는데 나머지 방법 중에서는 쿠키가 가장 보안이 나아 보이네요 😁 3의 http only를 사용하면 Csr환경에서 접근이 불가능해서 탈락이라고 적어 주셧는데 Csr에서 접근을 해야 될 이유가 있는지 부터 먼저 고려해보겠습니다. 1. 토큰 내부의 정보가 필요하다 => 토큰을 받을 때 정보만 따로 body로 보내 전역변수에 관리한다 2. 클라이언트에서 요청 시 헤더에 담아야 한다 => http only 토큰은 클라이언트에서 따로 컨트롤 없이 서버에서 받아올 수 있습니다. http only의 경우 클라이언트에서 접근 불가라서 보안성이 더 높아지고 코드 인젝션 으로 부터 더 안전해지는 경향이 있다고 생각하기에 저는 오히려 장점으로 보여지는데.. 혹시 작성자 님이 고려한 CSR에서 꼭 접근해야 하는 이유에 대해 고려해보시고 Http only가 더 좋지 않을까 생각합니다. 혹은 많이 쓰는 방법으로 토큰을 2개로 분리 (엑세스 , 리프래쉬) 로 분류하여 리프레쉬의 경우 쿠키 - http only(최대한 안전하게) + 액세스의 경우 csr로 받아와 전역변수에 넣고 관리 이렇게 사용하는 것도 괜찮을 것 같습니다.
익명
작성자
2024년 03월 14일
답변 감사합니다! 제가 왜 사용해야되는지에 대해서 설명을 조금 불명확하게 작성해놓은 부분이 있는 것 같네요 ㅜ 일단 백엔드 서버는 따로 구성이 되어있으며, http only 쿠키로만 외부 서버랑 통신하려면 도메인 주소가 같아야되는데, 그 부분에 있어서 개발단계에서는 불편함과 어려움이 많았습니다. 그래서 csr이든 ssr이든 axios 인터셉트에서 직접 header bearer에 담아줘야되기 때문에 그랬습니다. 두번째 말씀해주신 방향은 accessToken refresh가 필요한 경우에는 api route 기능을 사용해서 받아온다 이런 흐름일까요? 좋은 방향인 것 같네요! 감사합니다!
백승훈
프론트 엔드 개발자 (FE) • 2024년 03월 15일
아.. 쿠키가 secure 문제로 사용이 안되서 아예 배제 하신거 라면 로컬이나 전역말고는 선택지가 없긴 하네요.. 😥
이정윤
소프트웨어 개발자 • 2024년 03월 15일
httpOnly 쿠키를 사용할 때 개발단계에서 있는 어려움이 무엇인지 궁금합니다… 제 경우에는 백엔드 서버와 nextjs 서버를 로컬에서 같이 띄우기만 한다면 개발환경이 불가능하지는 않던데요 😅
익명
작성자
2024년 03월 15일
넵. 서버를 로컬에서 같이 띄우면 당연히 문제 없습니다. 근데 프론트와 백엔드가 나뉘어져서 개발이 진행될경우에 어려움이 많습니다.서버 레포지토리도 함께 보면서 새로운 내용이 반영되었는지 직접 깃을 관리 해야되며, 자바, 파이썬 등 사용하지 않는 언어들의 버전도 함께 관리해야되는 문제가 있습니다. 불가능은 아니지만 ssr이 아니라면 고려하지 않을 어려움들이 있어서 그렇습니다 ㅜ
백승훈
프론트 엔드 개발자 (FE) • 2024년 03월 17일
엇.. 혹시 제 착각인지 모르겠지만 httpOnly 라던지 쿠키의 활용과 모노레포는 전혀 상관이 없습니다. Cors나 쿠키의 활용은 도메인이 동일 도메인인지 & 프록시를 통한 셋팅 등을 통해 해결가능하며 질문자님이 생각하시는 것은 약간 모노레포가 섞여있는 듯 합니다. 동일 환경에 띄우는 것이 아닌 개발환경 -> 백엔드의 주소와 맞춰줌(프록시를 통한 제어) 상용환경 -> 동일 도메인상에 배포 이렇게 하시면 둘 다 활용가능합니다. https://0422.tistory.com/329
익명
작성자
2024년 03월 22일
제 얘기는 모노레포 얘기가 아니라 단순히 정윤님이 말씀하신 서버를 로컬에 띄우는 것이었습니다! 프록시로 개발환경을 구성하는 것도 방법이겠네요! 그게 제일 쿠키로만 통신하며 깔끔하겠군요. 근데 이미 구성된 서버가 header bearer에 담아주도록 되어 있어서 요런 경우에는 어쩔 수 없을 것 같네요 ㅜ
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 03월 13일
Next.js에서 토큰을 안전하게 처리하는 가장 기본적인 방법은 서버사이드 렌더링(SSR)에 필요한 정보를 가져오는 `getServerSideProps` 에서 **httpOnly 쿠키**를 사용하는 것입니다. 이 방식은 CSR 환경에서는 접근할 수 없지만, Next.js 앱의 서버사이드에서는 가능합니다. csr환경에서 필요하다면 accessToken 같은 보안이 크리티컬하지 않은 토큰을 localStorage나 state로 관리해도 됩니다. 그러나 최고의 보안성능을 위해서는 httpOnly 쿠키와 보안된 연결(HTTPS)을 사용한다면, 일반 쿠키에 비해 더 안전하게 토큰을 처리할 수 있습니다. 아래는 일반적인 Next.js 앱에서 서버 사이드 렌더링과 httpOnly 쿠키를 함께 이용하여 토큰을 처리하는 예시입니다. ```jsx import axios from "axios"; export async function getServerSideProps(context) { const token = context.req.cookies.token; const config = { headers: { Authorization: `Bearer ${token}` } }; const data = await axios.get("/api/data", config); return { props: { data }, // will be passed to the page component as props }; } ``` 그러나, 이 방식도 완벽하진 않습니다. httpOnly 쿠키 자체가 XSS 공격으로부터는 안전하나 CSRF 공격에 취약한 점이 단점입니다. 이를 보완하기 위해선 CSRF 토큰을 사용하는 방법 등 다양한 해결책들이 있습니다. 따라서, 어떤 방식을 선택할지는 프로젝트의 요구사항과 기술적인 제약 사항에 따라 달라질 것입니다. 중요한 것은 어떤 방식이든 그 방식의 장단점을 충분히 이해하고 적용하는 것입니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!