세션 방식을 선택한 이유

세션 방식을 택한 이유

• 저번 연습 프로젝트에서는 로그인 시 jwt 토큰 방식을 선택했다. 그리고 이번 프로젝트에서는 session 방식을 선택했다.
• 세션과 토큰 방식의 차이점을 찾아보면, 세션이 안정성이 높고 사이즈가 작아서 네트워크 부하가 작다는 등의 여러 장점이 나온다.
• 하지만 그런 이유보다는 '제대로 안써봐서' 써보기 위해 선택했다. 배우는 단계에서는 이것저것 다양한 기술을 구현해보는 경험도 중요하다고 생각했다.

 

토큰 방식을 사용했을 때의 문제점들

•  로그아웃이 애매하다.
  • 일단 한 번 발급한 토큰은 무효가 안된다. 그래서 보통 redis에 블랙리스트를 사용하는데, redis 에 블랙리스트로 저장한다는 것은 결국 서버를 stateful 하게 사용하게 된다. 토큰의 tateless 한 장점이 없어진다.
  • 나같은 경우에는 어떻게 할까 고민하다가 토큰에 빈 칸 "" 을 넣어서 다시 전달하는 방식으로 로그아웃을 구현했었다.
• payload 에 많은 정보를 담을 수 없다.
  • 나는 너무나 당연하게 헤더와 페이로드가 암호화되어서 못볼 것이라고 생각했었다. 그러나 base64로 인코딩할 뿐이고 실질적으로 signature 부분만 암호화한다. 그래서 페이로드는 누구나 디코딩하여 확인이 가능하므로 다른 정보들을 넣어서는 절대 안된다. 처음엔 이것을 몰라서 이것저것 정보를 넣어서 토큰을 발급했다가 추후에 알고 놀랐던 적이 있다....!
• access token 과 refresh token 발급
  • 결국 토큰을 클라이언트에 저장해두기 때문에 탈취 위험이 있고, 앞서 말했듯 한 번 발급한 토큰은 무효가 안되어 유효시간을 짧게 생성한다. 그리고 refresh token 을 추가로 발급하여 유저의 인증과 인가 시간을 연장해준다. 이때 refresh token 은 보통 서버에 저장한다. 이 또한 redis와 마찬가지로 stateless 하다는 토큰의 장점이 사라진다. 

세션 방식을 선택한 후 발생한 문제점들

• 세션 데이터를 서버에서 저장하고 관리
  • 세션을 서버에서 관리해야 하므로 사용자 수가 증가하면 서버 부하가 증가할 수 있다.
  • 서버의 메모리에 저장되므로 서버 확장 시 여러 서버 간에 세션 데이터를 공유하려면 별도의 메커니즘을 구현해야 하므로 고민이 필요하다.
• stateful 한 문제
  • RESTful 아키텍처의 핵심 원칙 중 하나는 stateless (무상태성)이다. stateless 는 각 http 요청이 독립적이며 이전 요청과 관계 없이 처리가 되어야 한다. 상태를 클라이언트 측에서 관리하고 서버에 의존하지 않는 것이 중요하며 이전 요청에 대한 상태를 유지하지 않아야 한다. 세션을 사용하면 이전 요청에 대한 상태 정보를 저장하고 관리해야 하므로 무상태성 원칙에 어긋난다.

세션 방식을 선택함으로써 이점들

• 사용자의 상태 정보를 추적하고 관리할 수 있다. 로그인 상태, 장바구니, 설정 등 사용자 관련 정보를 저장하고 유지가 가능하다. 이전 활동 내역이나 기호에 따라 적합한 콘텐츠나 제품을 추천할 수 있다.
• 임시 저장할 수 있는 게시글, 작업 기록, 임시 드래프트 등 상태 관리가 필요할 때 세션을 통해서 수행 가능하다.
• 여러 HTTP 요청 간의 데이터를 공유할 수 있으므로 일관된 사용자 상태를 유지할 수 있다.
• 사용자 관리와 여러 작업을 간단하게 만들어주고 편리성과 기능성을 향상시킨다.

세션 동작 원리

1. 클라이언트의 요청이 들어오면 WAS 에서 세션키를 생성한다.
2. 서버는 세션키를 담은 쿠키를 포함하여 응답한다.
3. 이후 클라이언트의 요청 시 쿠키에 세션키를 담아 서버에 전송하여 요청한다.
4. 서버는 쿠키에 담긴 세션키를 검증 후 응답한다.

마무리

• 추가적으로 aop에 대해서 더 공부하고 반복되는 로직들에 대해서 리팩토링이 필요할 것 같다.
• 아직 인프라 구성에 대해서는 어렵고 공부해야할 것들이 많다. 기본적인 기능 구현이 끝나면 애플리케이션 서버 2개와 앞 단에  session clustering 을 사용하는 방식으로 구현해보고 싶다.