Session & Cookie
Session이란?
Cookie는 일상생활에서도 종종 들을 수 있는 단어다. 간단히 말하자면 Client 측의 브라우저에 저장되는 일종의 '정보'인데, 이를 통해 어딘가에 요청을 보낼 때 Request Header에 자동으로 딸려서 전송된다. ( 물론, 설정에 따라 모든 쿠키가 전송되는 것은 아님! )
그렇다면 Session은 무엇이길래 Cookie와 같이 언급이 되는 걸까?
Cookie와 Session의 차이점은 여러가지 있지만, 그 중에서도 정보가 저장되는 위치에 근본적인 이유가 있다.
Cookie와 Session은 이 하나의 차이점으로 구분된다해도 과언이 아니다.
Session과 Cookie를 사용하는 곳은 서버에 저장되는 정보가 비교적 안전하기 때문에 인증관련 정보는 Session으로 보통 관리를 하는데, 그 외에는 서버에 과부하를 줄이기 위해 Cookie를 사용하는 편이다
쿠키와 세션을 사용하는 이유
쿠키와 세션을 사용하는 근본적인 이유에는 HTTP 프로토콜의 특징에 있다
→ HTTP 프로토콜은 connectionless와 stateless 한 특성이 있다.
⇒ 그럼 쿠키는 그렇다쳐도... 세션 대신 DB를 통해 상태를 관리하면 되지 않을까? → 매번 갱신되고 삭제되는 정보를 DB로 관리하고, 자주 요구되는 정보를 매번 DB에 접근해서 얻어내기에는 과부하가 크다
⇒ 따라서 이러한 특성으로 인해 발생하는 문제점들을 해결하기 위해 정보를 저장 & 유지하기 위해 쿠키와 세션을 사용한다.
쿠키
주요 특징
- 서버측에서 Response Header에 Set-Cookie 속성을 사용해서 클라이언트에 쿠키를 만들 수 있다
- 쿠키는 사용자가 따로 Request에 담지 않아도, 자동으로 Request Header에 담겨서 서버에 전송된다
- 쿠키는 클라이언트 측에 저장된다
- 쿠키의 유효 시간이 정해지면, 브라우저가 종료되어도 유지된다
구성 요소
- 키 : 구별자
- 값 : 구별자에 해당하는 value
- 유효시간 : 쿠키의 유지 시간
- 도메인 : 쿠키를 전송할 도메인
- 경로 : 쿠키를 전송할 요청 경로
동작 방식
- 클라이언트가 서버에 request를 보냄
- 서버에서 쿠키를 생성
- HTTP 헤더에 Set-Cookie를 포함시켜서 response
- 브라우저가 종료되어도 쿠키 만료 기간이 있으면, 클라이언트에서 보관
- 해당 도메인 혹은 경로로 요청을 할 때, HTTP 헤더에 쿠키를 담아서 request 전송
- 서버에서 쿠키를 읽고, 이전 상태를 변경할 필요가 있을 경우, 쿠키를 업데이트하여 변경된 쿠키를 Set-Cookie로 포함해서 response
세션
- 세션은 서버 측에 저장된다
- 서버는 클라이언트를 구분하기 위해 세션 ID를 부여해서 브라우저가 종료될 때까지 인증 상태를 유지한다
- 세션의 유효 시간이 정해지면, 브라우저 종료 혹은 시간 만료까지 유지된다
- 보안 측면에서는 쿠키보다 좋지만, 서버 메모리를 차지한다
동작 방식
- 클라이언트가 서버에 request를 보냄
- 서버는 해당 클라이언트에게 세션 ID를 부여하고 Set-Cookie를 통해 쿠키를 생성
- 클라이언트는 서버에 request를 보낼 때, 해당 세션 ID를 포함해서 전송
- 서버는 세션 ID를 기반으로 세션에 있는 클라이언트 정보를 가져옴
- 해당 세션 정보로 request를 처리하고 response
JWT
JWT란?
사실 JWT 자체가 인증 방법이 아니라, Token 기반 인증 방법이지만, 일반적으로 이에 JWT를 사용하여 이렇게 불린다
( 개인적으로 JWT보다 단순히 Token 기반 인증이라고 생각하면 이해가 좀 더 편한 것 같다 )
JWT와 Session의 가장 큰 차이점은 정보가 서버에 저장되는 것이 아니라 클라이언트가 저장하고 있다는 것이다
→ 하지만 이를 서버에서 암호화시켜서 클라이언트에게 전송해주고, 받을 때는 복호화하여 인증하기 때문에 보안을 유지할 수 있는 것이다
동작방식
- 클라이언트가 서버에 Request를 보냄
- 서버는 해당 클라이언트의 인증 정보와 암호키를 기반으로 암호화시켜 token을 발급함
- 발급된 토큰을 클라이언트에게 전송 ( Set-Cookie도 가능 )
- 클라이언트는 저장하고 있다가 Header에 포함시켜 보냄
- 서버는 매 요청마다 Header에 포함된 token을 복호화하여 검증하고 유저에게 권한을 부여함
JWT와 Session 비교
JWT
장점
- 클라이언트에 저장되기 때문에, 서버 메모리에 부담되지 않는다
- Session 사용할 때의 Scale Out 관련 에러사항이 발생하지 않는다
- 멀티 디바이스 환경에 대한 부담이 없다
단점
- XSS 공격에 취약하다
- 상대적으로 손상의 위험이 크다
Session
장점
- 구현이 간편하고 명확하다
- 서버에서 로그인 상태 확인이 편하다
- 상대적으로 안전하다
단점
- 서버 메모리에 부담이 된다
- Scale Out시, Session 정보를 어떻게 통일시킬 것인지 이슈가 발생한다
- 멀티 디바이스 환경에 대한 부담이 생긴다
따라서 현재 진행하고자 하는 프로젝트에서 MSA 환경을 최종적인 목표로 하는 만큼, JWT를 사용하여 이와 관련된 이슈 문제점을 미연에 방지하고자 한다
