[CS] Session vs Token

HTTP 프로토콜 특징

• Connectionless 프로토콜
  • 클라이언트가 서버에 요청하면 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리 방식
• HTTP는 stateless한 특성이 있기에 통신 상태가 저장되지 않는다. -> 정보유지가 불가능
• 이 문제를 해결하기 위한 대표적인 도구가 Session 과 Token

Cookie

• Key-Value 형태의 문자열
• 웹 서버가 브라우저에게 지시해 사용자의 로컬에 파일 또는 메모리에 저장하는 작은 기록 정보 파일
• 파일에 담긴 정보는 인터넷 사용자가 같은 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 았다.
• 동작
  • 클라이언트가 페이지 요청
  • 웹서버 쿠키 생성
  • 쿠키에 정보를 담아 HTTP화면을 돌려줄 때 같이 클라이언트에게 준다.
  • 쿠키는 클라이언트가 가지고 있다가 다시 서버에 요청할 때 요청과 함께 쿠키 전송
  • 동일 사이트 재방문 시 클라이언트 PC에 해당 쿠기가 있는경우, 요청 페이지와 함께 쿠키 전송
• 단점
  • 보안에 취약
    • 요청시 쿠키 값을 그대로 보낸다
    • 유출 및 조작 당할 위험
  • 용량 제한이 있어 많은 정보를 담을 수 없다.
  • 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유 불가능
  • 쿠키의 사이즈가 커질수록 네트워크에 부하

Session

• 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보는것
• 웹 컨테이너의 상태를 유지하기 위한 정보 저장
• 서버에서 세션을 삭제했을 때만 삭제되므로 쿠키보다 비교적 보안이 높음
• 쿠키를 포함한 요청이 외부에 노출되더라도 SessionID 자체는 유의미한 개인정보를 담고 있지 않다.
  • 중간에 탈취하여 클라이언트인척 위장가능
• 고유 SeesionID가 발급되기 때문에 요청이 들어올 때마다 회원정보를 확인할 필요가 없다.
• 서버에서 세션 저장소를 사용해 요청이 많아지면 서버에 부하가 심해진다.
• 세션은 서버의 저장소에 저장되고 빠른 응답을 위해 메모리에 상주시키는 경우가 많다. 이로 인해 서비스에 사용자가 몰렸을 경우 매 요청마다 세션을 확인해야 하므로 DB에 많은 부하를 일으키게 되고 메모리 부족으로 서비스 장애가 발생할 수도 있다. 클라우드를 이용하면 서버와 DB를 유연하게 증설할 수 있다고 하지만 그 시간동안에 서비스 장애를 겪을 수도 있다. Redis와 같은 인프라를 이용하여 메모리에 상주하는 세션을 좀 더 빠르게 처리하도록 하는 방법을 사용하기도 한다.

Token

• JWT(JSON Web Token)
  • 인증에 필요한 정보들을 암호화시킨 토큰
• 구조
  • Header
    • 정보를 암호화할 해싱 알고리즘 및 토큰의 타입 지정
  • Payload
    • 토큰에 담을 정보를 가지고 있다.Key-Value형태로 이루어진 한 쌍의 정보 -> Claim
  • Signature
    • Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성

Refresh Token

• 클라이언트가 로그인 요청을 보내면 서버는 Access Token 및 그보다 긴 만료 시간을 가진 Refresh Token을 발급하는 전략
• Access Token이 만료되면 Refresh Token을 사용하여 Access Token 재발급 요청

Session vs Token

• Size
  • 세션을 주고 받는 sessionId의 크기는 작다. 반면 토큰은 같은 데이터를 담고 있어도 그에 비해 크기가 크다.
• 안전성
  • Session
    • 서버측에서 저장/관리하기 때문에 상대적으로 온전한 상태를 유지하기 좋다.
    • 하지만 여전히 공격 위험이 있어 유효기간,HttpOnly,Secure옵션 등을 주어 쿠키에 저장
  • Token
    • 웹브라우저측에 저장되기 때문에 노출 가능성이 더 크다. 그러므로 토큰에는 민감한 정보를 담지 않는다.
    • 유효기간을 짧게 설정해 공격에 노출될 수 있는 시간을 최소화 한다.
    • 하지만 짧은 주기로 토큰이 무효화되면 사용자는 계속 로그인을 해줘야하는 번거로움이 있어 Refresh Token 추가 발급
• 확장성
  • 세션은 서버에 저장되기 때문에 한꺼번에 다중 접속자가 생기면 과부하 위험
  • 이런 단점을 해결하기 위해 sticky session, session clustering과 같은 방안이 나오긴 했지만 비용이 그만큼 발생
  • 토큰은 추가 서버 없이 인증/인가 처리 가능