로그인 방식에 대한 이해(세션 vs 토큰)

Mayton·2022년 12월 20일
0

ComputerScience

목록 보기
1/7
post-thumbnail

Next.js를 숙달을 위해 당근마켓 클론 코딩을 진행하던 중 지금까지는 JWT를 사용해 왔기때문에 세션 방식을 이용한 로그인을 적용하려고 하였다. 그동안 헷갈렸던 부분들을 정리하기위해 블로깅해보려고 한다.

🙋🏻‍♂️HTTP의 특징

로그인방식으로 바로 들어가기 전에 HTTP의 특징을 알아야, 세션방식과 토큰방식이 어떻게 다른지, 왜 사람들이 이렇게 두 방식으로 나누었는지를 제대로 이해할 수 있다.

👉🏻Connectionless란?

Connectionless란 서버의 요청과 응답이 모두 일어난 이후에는 TCP/IP연결을 유지하지 않는 것이다. 이를 통해 서버의 자원을 효율적으로 관리하고, 수 많은 요청과 응답을 처리할 수 있다.

ps. 응답, 요청이후 새로 연결 될때 3-way handshake과정이 다시한번 반복되어야 하기 때문에 웹 사이트의 콘텐트가 늘어나면서 TCP 연결의 재사용이 필요하였고, Persistent Connection 기술이 나오게 되었다. HTTP/1.1버전부터 Connection:keep-alive를 헤더에 보내는 방식으로 Persistent Connection을 지원하였으며, HTTP/2 버전부터는 멀티플렉싱 기능을 통해 단일 TCP 연결을 통한 다수의 HTTP요청과 응답이 클라이언트와 서버사이의 응답 지연없이 Stream형태로 주고 받을 수 있게 되어 Persistent Connection의 고민을 덜었다.

👉🏻Stateless란?

stateful 하다는 것이란?

stateful 서버란 클라이언트의 요청을 받을 때마다 그 클라이언트의 상태를 계속해서 유지하고, 서비스 제공에 이용하는 것이다.

stateless

반대로 상태를 유지하지 않는 것을 stateless라고 한다. 이전 상태정보를 저장하지 않으면서 서버는 클라이언트측에서 들어오는 요청만으로 작업을 처리한다. 이 때 결합도가 낮아 서버의 확장성이 높아진다.

아래의 예제를 보고 stateless의 의미를 확실히 이해할 수 있었다.

stateful
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.

승객: 2장 주세요.
직원: 50,000원입니다. 결제는 무엇으로 하시겠습니까? (KTX 노선과 주문 수량에 대한 상태를 유지)

승객: 체크카드입니다.
직원: 결제과 완료되었습니다. (KTX 노선과 주문 수량, 결제 수단에 대한 상태를 유지)

stateless
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.

승객: 2장 주세요.
직원: ??? 무엇을 2장 구매하시는 건가요???

승객: 아까 말했잖아요😳. 서울에서 전주 가는 KTX요!!!
직원: 몇 장인지, 결제 수단은 무엇인지 한 번에 얘기해주세요!

🔐 토큰기반 로그인

작동원리

  • 인증에 필요한 정보를 암호화 시킨 토큰을 주고 받아 사용자 인증을 한다.
  • 사용자는 Access Token을 HTTP 헤더에 실어 서버로 보낸다.

  1. 유저가 아이디와 비밀번호로 로그인을 한다.
  2. 서버측에서 해당 계정정보를 검증한다.
  3. 계정정보가 정확하다면, 서버측에서 유저에게 서명된 토큰을 발급해 준다.
  4. 클라이언트 측에서 전달받은 토큰을 저장해 두고, 서버에 요청을 할 때마다, 해당 토큰을 함께 서버에 전달한다.
  5. 서버는 토큰을 검증하고 요청에 응답한다.

장점

  1. 별도의 저장소가 필요없어 Stateless한 서버를 만들 수 있다.
  2. Stateless 서버를 만들기 때문에 서버를 확장(Scalability)하거나 유지, 보수하는데 유리하다.
  3. 클라이언트가 서버에 요청을 할 때 쿠키를 전달하지 않음으로 쿠키로 인한 취약점이 사라진다.
  4. SSO와 같이, 토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있으며, 토큰에 선택적 권한만 부여하여 발급할 수도 있다. (Extensibility)

단점

  1. 한번 발급된 JWT에 대해서는 돌이킬 수 없음 (Access Token의 유효기간을 짧게 하고, 지속적으로 Refresh Token을 발급하는 방식으로 진행)
  2. Payload의 정보가 제한적이다. (Payload는 따로 암호화 되지 않아 누구나 정보를 확인할 수 있어 중요 정보를 넣어서는 안된다.)

🖥️ 세션기반 로그인

작동원리

  1. 유저가 아이디와 비밀번호로 로그인을 한다.
  2. 서버에서 해당 계정정보를 검증한다.
  3. 사용자의 고유한 ID를 부여하여 세션 저장소에 저장 후 세션 ID를 발행한다.
  4. 유저는 해당 세션 ID를 쿠키에 저장한다.
  5. 데이터 요청 시 쿠키를 통해 유저의 상태를 저장 및 관리한다.

http의 특징 중 하나인 stateless에서 stateful하도록 만든 것이 세션을 이용한 방법이다. 서버에서 유저의 로그인 상태를 관리하는 인스타그램, 페이스북 같은 경우도 세션을 통해 유저의 상태를 확인한다.

장점

  1. 구현이 명확하고 실제 서버에서 로그인 상태 확인이 유용하다.
  2. 서버측에서 로그인을 관리하기 때문에 클라이언트 단에서의 변조나 영향 받거나 손상의 우려가 없다.

단점

  1. 유저들의 세션에 대한 정보를 저장할 공간이 필요하다.
  2. 서버 메모리에 세션 정보가 저장 되기 때문에 결국 유저 상태에 무관하게 동작하는 Datat-Driven 아키텍쳐가 요구된다.
  3. 멀티 디바이스 환경에서의 작업이 조금 더 복잡하다.
  4. 쿠키 탈취로 인한 취약점이 존재한다. (세션의 유효시간을 지정한다)
  5. CORS 문제가 발생한다. (다른 도메인에서의 요청은 무력화되는 문제)

참고

profile
개발 취준생

0개의 댓글