인프런 커뮤니티 질문&답변
작성한 질문수
next-auth 사용 이유
작성
·
122
0
안녕하세요.
백엔드에서 connect.sid 쿠키와 next-auth의 auth.js-session-token을 사용해서 유저 인증을 하는 것 처럼 보입니다.
프론트서버에서 유저가 접근 시 세션 쿠키(connect.sid)를 받아 백엔드에 유저 세션을 확인한다면 next-auth를 사용하지 않아도 되는 것처럼 보입니다.
백엔드에서 auth.js-sessoin-token으로 유저 인증을 한다면 역시 세션 쿠키(connect.sid)가 필요없는 것처럼 보입니다.
connect.sid와 auth.js-session-token 쿠키를 모두 사용해야 하는 이유가 있을까요?
만약 둘 다 사용하는게 좋다고 한다면 동기화가 필요할 것 같은데(만료 시간, 세션 무효화 등..), 이건 어디서 어떻게 처리하는게 좋을까요?
(예외 질문) connect.sid의 쿠키에 httpOnly 옵션이 false여도 괜찮은가요?
혹시 백엔드에서 connect.sid의 쿠키를 httpOnly로 보냈다면 쿠키파싱이 제대로 안된 것 같습니다. 아래 모듈로 쿠키파싱하면 되는 것 같습니다. 혹시나하고 남겨봅니다.
//현재 코드
//import cookie from "cookie";
//const parsed = cookie.parse(setCookie);
import { parseSetCookie } from "next/dist/compiled/@edge-runtime/cookies";
const parsed = parseSetCookie(setCookie);
답변 2
1
현재 백엔드서버는 auth.js-session-token을 받을 수 있습니다(동기화가 되어 있습니다). 따라서 connect.sid는 사용하지 않습니다.
https://github.com/ZeroCho/nest-prisma/blob/d77f35ef9d08bcc69a2253e67a58e10041bf91c3/src/auth/parse-session-token-guard.ts
Next14 버전강좌까지는 토큰을 두 개 사용하였으나, Next15 버전 리뉴얼 촬영하면서 auth.js-session-token만 사용하도록 강의를 수정했습니다.
쿠키의 httpOnly 옵션은 다시 확인해보니 켜져있네요. https://github.com/ZeroCho/nest-prisma/blob/b6955d9c7f0bcc20311b58823a6d7ccdb6bc4580/src/app.module.ts#L75
쿠키 파싱이 안되어 어떤 부분에서 문제가 발생하나요?
connect.sid 내부에는 정보가 없어서 프론트에서 파싱하기 좀 어렵습니다. auth.js-session-token은 jwe 토큰이라 파싱할 수 있습니다.
connect.sid 생성하지만 nextjs 서버가 브라우저로 보내지 않습니다.
connect.sid는 배포 시에는 httpOnly여야합니다. z.nodebird.com은 next14버전 코드입니다. nest-prisma 레포지토리의 백엔드를 직접 실행해보시는 게 좋습니다
감사합니다!
혹시 그렇다면 connect.sid를 생성하는 이유가 있을까요?
auth.js-session-token만으로 백엔드와 next에서 유저 인증을 하는 것처럼 느껴집니다.
connect.sid 생성하지만 nextjs 서버가 브라우저로 보내지 않습니다.
connect.sid는 백엔드에 직접 이메일/비밀번호 로그인 시 생성됩니다. 지금 서비스는 백엔드에는 로그인하지 않고 프론트에서 발급받은 토큰으로만 인능합니다. 즉 최신 코드로는 connect.sid가 브라우저에 보이지 않습니다. 과거 버전의 코드를 보셔서 그렇습니다.
최신 코드에서는 아래와 같이 이해하면 될까요?
connect.sid는 백엔드에서 생성만하고 어디에서도 사용하지 않는다.
백엔드는 프론트에서 발급 받은 토큰으로만 유저인증한다.
0
안녕하세요, 인프런 AI 인턴입니다.
송지훈님께서 주신 질문에 대한 답변을 드리겠습니다. 여러 가지 성격의 질문을 주셨고, 이는 백엔드와 프론트엔드의 세션 관리와 인증 시스템에 대한 본질적인 이해를 요구하는 중요한 부분입니다. 이런 내용들에 대해 상세히 이해하고, 시스템 설계에 반영하는 것은 매우 중요합니다. 각각의 질문에 대해 간단히 답변을 드리겠습니다.
세션 쿠키(connect.sid) 없이 next-auth 사용:
- next-auth는 주로 클라이언트 사이드에서 사용할 수 있는 편리한 인증 라이브러리입니다. 백엔드에서도 사용자 인증을 처리할 때 유용하게 사용할 수 있습니다. 모든 사용 사례에서 반드시 next-auth가 필요한 것은 아니지만, 여러 인증 제공자나 소셜 로그인 등을 쉽게 구현할 수 있게 도와줍니다.
- next-auth는 주로 클라이언트 사이드에서 사용할 수 있는 편리한 인증 라이브러리입니다. 백엔드에서도 사용자 인증을 처리할 때 유용하게 사용할 수 있습니다. 모든 사용 사례에서 반드시 next-auth가 필요한 것은 아니지만, 여러 인증 제공자나 소셜 로그인 등을 쉽게 구현할 수 있게 도와줍니다.
세션 쿠키 없이 auth.js-session-token 사용:
- 백엔드에서 auth.js-session-token을 활용한다면, connect.sid와 같은 전통적인 세션 쿠키를 사용하지 않을 수도 있습니다. 두 시스템이 사용하는 방식이 다르면, 관리가 번거로울 수 있어 적절한 선택이 필요합니다.
- 백엔드에서 auth.js-session-token을 활용한다면, connect.sid와 같은 전통적인 세션 쿠키를 사용하지 않을 수도 있습니다. 두 시스템이 사용하는 방식이 다르면, 관리가 번거로울 수 있어 적절한 선택이 필요합니다.
두 쿠키를 모두 사용해야 하는 이유:
- 두 가지를 모두 사용하게 되면 인증과 권한 관리의 유연성이 증가할 수 있습니다. 그러나, 복잡성이 증가함에 따라 관리가 어려워질 수 있습니다. 사용 목적과 환경에 따라 선택지가 달라져야 합니다.
- 두 가지를 모두 사용하게 되면 인증과 권한 관리의 유연성이 증가할 수 있습니다. 그러나, 복잡성이 증가함에 따라 관리가 어려워질 수 있습니다. 사용 목적과 환경에 따라 선택지가 달라져야 합니다.
동기화 및 관리 방안:
- 쿠키 간 동기화는 일반적으로 세션 관리 라이브러리나 미들웨어를 통해 이루어집니다. 세션 무효화 및 만료 시간을 지속적으로 체크하고 관리합니다. 이 작업은 백엔드 로직에서 처리해야 할 부분입니다.
- 쿠키 간 동기화는 일반적으로 세션 관리 라이브러리나 미들웨어를 통해 이루어집니다. 세션 무효화 및 만료 시간을 지속적으로 체크하고 관리합니다. 이 작업은 백엔드 로직에서 처리해야 할 부분입니다.
httpOnly 옵션의 중요성:
- httpOnly 옵션이 false로 설정되면 클라이언트 측 코드에서 쿠키에 접근할 수 있어 보안상 매우 위험합니다. 가능하면 httpOnly 옵션을 true로 설정하여 XSS 공격으로부터 보호하세요.
- httpOnly 옵션이 false로 설정되면 클라이언트 측 코드에서 쿠키에 접근할 수 있어 보안상 매우 위험합니다. 가능하면 httpOnly 옵션을 true로 설정하여 XSS 공격으로부터 보호하세요.
쿠키 파싱 문제:
- 말씀하신 것처럼, 쿠키 파싱 문제는 다양한 방법으로 해결 가능하며, next.js의
parseSetCookie모듈을 사용하면, 쿠키를 보다 안전하고 효과적으로 파싱할 수 있습니다.
- 말씀하신 것처럼, 쿠키 파싱 문제는 다양한 방법으로 해결 가능하며, next.js의
이와 관련해 강화된 이해를 위해 관련 학습 자료나 문서를 참조하는 것도 매우 도움이 될 것입니다. 다만, 직접적인 해결책을 원하신다면, 프론트엔드 세션과 백엔드 세션 / queryClient.getQueryCache에 대한 질문이 있습니다! 이 질문에서 비슷한 맥락의 문제에 대한 이해를 돕는 좋은 사례를 확인해보실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
엄청 빠른 답변 감사합니다.
아래의 답변에서 백엔드의 세션쿠키와 auth.js-session-token 중 하나를 선택하면 될 것 같은데 auth.js-session-token 을 선택한 이유가 궁금합니다.
그럼 백엔드에서는 유저 인증을 위한 토큰이나 쿠키를 생성하지 않는게 맞을까요?
Next14 버전강좌까지는 토큰을 두 개 사용하였으나, Next15 버전 리뉴얼 촬영하면서 auth.js-session-token만 사용하도록 강의를 수정했습니다.
아래의 질문주신건에 대하여 next ->브라우저로 connect.sid 쿠키를 보낼 백엔드가 보낸 쿠키가 제대로 파싱되지 않아서 브라우저로 쿠키 옵션이 안넘어가는 것 같습니다.
사용하는데 문제는 없는데 실무에서 저렇게 httpOnly가 false여도 되는지 궁금합니다
쿠키의 httpOnly 옵션은 다시 확인해보니 켜져있네요. https://github.com/ZeroCho/nest-prisma/blob/b6955d9c7f0bcc20311b58823a6d7ccdb6bc4580/src/app.module.ts#L75
쿠키 파싱이 안되어 어떤 부분에서 문제가 발생하나요?