인프런 커뮤니티 질문&답변
작성한 질문수
로그인 방식 관련해서 질문드립니다!!
작성
·
37
0
로그인 방식을 구현하면서, 쿠키로만 개발할 경우 완전히 백엔드에 의존하게 되어 로컬로, 동시에 키고 개발을 하지 않는이상, 도메인간 불일치를 해결 할 방법이 없어, msw를 사용해야 한다고, 이전에 말씀해주셨습니다!!
보통, 회사나, 개인 소프트웨어를 만들 때 어떤 방식으로 로그인을 주로 만드시는지 조금 알고 싶어 궁금하여 질문을 남깁니다!!
로그인 방식 고찰
로그인 성공시, accessToken을 body로 받고, refreshToken은, httpOnly 쿠키로 받는 경우 (서버에서, DB or Redis를 통해 refreshToken 관리) → 인증 필요 요청 (Bearer accessToken), 리프레시 필요 요청 (refreshToken 심긴 쿠키를 바탕으로 요청)
- DB에서 관리하는 것 보다, redis를 통해 관리했을 떄 읽기 속도가 빠름을 확인!응답: accessToken과 refreshToken 모두 body로 클라이언트에게 전달.
인증 필요 요청과, 리프레시 토큰 재발급 요청 모두 헤더의 Bearer에 accessToken이나, refreshToken을 넣어서 전달.)
현재 방식: accessToken, refreshToken 모두 쿠키로 응답받고, 요청또한, 쿠키를 포함하여 전달.
제로초님은, Next.js를 활용하여, 웹 사이트를 만드실 떄, 어떠한 방식으로 로그인을 구현하시는지 궁금하고, 많은 회사에서 사용하는 방식은 보통 어떤 방식인지도 알고싶습니다!
답변 2
0
저는 웹사이트만 있을 때는 세션 쿠키 기반으로만 로그인 진행하는 경우가 많고, 모바일이나 api 서비스를 할 때 액세스 토큰을 사용하곤 합니다. 이 둘에서는 어차피 쿠키가 지원되지 않아서 토큰 방식 로그인이 훨씬 더 편합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 김용민님.
로그인 방식과 관련해 다양한 접근 방법이 있습니다. 각 방식은 특정 요구사항이나 환경에 따라 선택될 수 있는데요, 여기에 몇 가지 일반적인 로그인 구현 방식을 소개해 드리고자 합니다:
Access Token과 Refresh Token을 이용한 방식:
- 로그인 성공 시 Access Token을 클라이언트 측에 전달하고, Refresh Token은 보다 안전하게 HttpOnly 쿠키로 전달하는 방식이 많이 사용됩니다. 서버 측에서는 Refresh Token을 데이터베이스나 Redis와 같은 캐시 시스템에서 관리하여 보안성과 성능을 동시에 확보할 수 있습니다. 이 방식은 보안과 성능을 동시에 고려한 매우 효율적인 방법입니다.
- 관련된
redis를 활용하면 토큰 검증 속도를 크게 높일 수 있습니다. 실질적으로 데이터베이스보다 읽기 속도가 더 빠르기 때문입니다.
- 로그인 성공 시 Access Token을 클라이언트 측에 전달하고, Refresh Token은 보다 안전하게 HttpOnly 쿠키로 전달하는 방식이 많이 사용됩니다. 서버 측에서는 Refresh Token을 데이터베이스나 Redis와 같은 캐시 시스템에서 관리하여 보안성과 성능을 동시에 확보할 수 있습니다. 이 방식은 보안과 성능을 동시에 고려한 매우 효율적인 방법입니다.
모든 토큰을 Body로 전달:
- 두 토큰 모두를 응답의 Body로 제공하고, 필요한 경우 헤더에 Bearer로 전송합니다. 이 접근 방식은 주로 SPA와 같은 클라이언트에서 토큰을 저장하기 쉽게 하기 위해 사용되며, 이는 로컬 저장소에서의 보관 측면에서 부작용이 있을 수 있습니다.
- 두 토큰 모두를 응답의 Body로 제공하고, 필요한 경우 헤더에 Bearer로 전송합니다. 이 접근 방식은 주로 SPA와 같은 클라이언트에서 토큰을 저장하기 쉽게 하기 위해 사용되며, 이는 로컬 저장소에서의 보관 측면에서 부작용이 있을 수 있습니다.
모든 것을 쿠키로 관리:
- Access Token과 Refresh Token을 모두 쿠키 기반으로 처리하며, 클라이언트와 서버 간의 인증 흐름이 간단해질 수 있습니다. 이 방식은 특히 쿠키 관리가 용이한 서버 측 렌더링 환경에서 유용하게 사용됩니다.
- Access Token과 Refresh Token을 모두 쿠키 기반으로 처리하며, 클라이언트와 서버 간의 인증 흐름이 간단해질 수 있습니다. 이 방식은 특히 쿠키 관리가 용이한 서버 측 렌더링 환경에서 유용하게 사용됩니다.
제로초님과 같은 전문가들은 다양한 환경과 요구사항에 민감하게 반응하여 로그인 방식을 선택하시는 경향이 있습니다. 특히, Next.js를 사용한 프로젝트에서는 서버와 클라이언트 간의 인증/인가 흐름이 직관적이고 효율적일 수 있는 쿠키 기반 인증이 많이 선호됩니다. 하지만 이는 각 프로젝트의 보안 요구사항, 성능 고려사항에 따라 변경될 수 있습니다.
기업에서는 주로 보안과 성능의 균형을 맞추기 위해 다양한 캐시 시스템(Redis 등)을 활용하고 있으며, Access Token 유효성 검증을 빠르게 처리하도록 설계하는 경우가 많습니다. 쿠키와 로컬 스토리지를 활용한 혼합 인증 방식도 다양하게 사용되고 있습니다.
김용민님께서 적용하실 프로젝트의 특성에 맞춰 이 여러 가지 방식 중 가장 적절한 방법을 선택하시는 것을 권장드립니다. 이해를 돕기 위해 아래 비슷한 질문들을 참고하시기를 추천 드립니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.