Session vs Token vs Cookies에 대한 개념

Cookie

• 데이터를 옮기는 매개체
• (웹)서버가 브라우저에 지시해 사용자에게 저장하는 저장매체
• 웹 방문시마다 읽히고, 정보가 수시로 바뀐다.

• 쿠키를 통해서 서버는 브라우저에 데이터를 넣을 수 있다. (유저에 대한 기억을 위해)
• 서버의 response에 쿠키가 담기게 된다.
• 쿠키는 서버가 정한 기간에 따라 유효기간이 있다.
• 브라우저에만 존재 (iOS, Android와 같은 네이티브 앱에는 없다.)

문제점

• Http Header에 담아서 보내기 때문에 트래픽이 발생할 수 있음
• 중요한 정보를 쿠키에 담는 경우 보안 문제 발생 가능
• 브라우저에만 존재 (iOS, Android와 같은 네이티브 앱에는 없다.)

---

Session

HTTP

• http는 Stateless
  • Stateless : 서버에 요청하는 모든 request는 각각 독립
  • request가 끝나면 서버는 대상이 누군지 모른다.
    ⇒ request마다 요청자가 누구인지 확인해야 함

개념

• 요청자를 확인하는 방법 중 하나가 Session
• 로그인한 유저에 대한 정보를 Session ID 형태로 서버의 DB에 저장하는 방식
• 메모리에 저장하기 때문에 브라우저 종료시 사라짐

절차

유저 로그인 시

1. 유저가 로그인(id, pw 입력)을 하게 되면 User DB에서 유저 정보 확인
2. 유저 정보가 맞다면 Session DB에서 Session ID를 부여 후 서버에 전달
3. 서버는 Cookie에 Session ID를 담아 브라우저로 전송
4. 해당 Cookie를 가지고 브라우저를 사용하게 됨

Session ID 발급 후 브라우저 탐색

1. 브라우저(클라이언트)에서 Session ID가 담긴 Cookie를 서버로 전달
2. 서버는 Session ID를 Session DB에서 탐색
3. Session ID를 가지고 User DB에서 유저 확인
4. 유저 확인이 완료되면 response
5. 1 ~ 4 과정을 브라우저에서 request를 보낼 때마다 반복

장점

• 서버에 정보를 저장하기 때문에 관리가 편함
• 해당 정보를 가지고 추가 기능 사용 가능 (강제 로그아웃, ...)

단점

• load-balancing된 서버라면 Session ID를 handling 하기 어렵다
  (1번 서버 접속 후 Session ID 발급 → 2번 서버 접속 시 재발급 받아야함)
  • Session 정보를 하나의 저장장치에 공유
• Session을 위한 물리적인 Database가 필요하다.
  • Redis와 같은 메모리 기반 저장장치 사용

---

JWT (Json Web Token)

• 토큰 형식
• Session DB가 필요없고, 서버의 유저 인증을 위한 작업들이 필요하지 않게 됨
• 토큰과 달리 공간의 제약이 없다.
• client가 가지고 있음

• 정보를 가진 Token (DB 없이 검증 가능)

Token

• 네이티브 앱(iOS, Android)에서 쿠키가 필요한 경우 사용 (서버에 토큰을 보냄)
• 긴 string
• 공간의 제약

• 서버가 기억하는 텍스트

로그인 예시

1. 유저의 id, pw를 서버에 전달 (Session과 동일)
   • id, pw가 맞다면 DB에 뭔가를 생성하지 않음
2. 유저의 ID 등을 가져가서 Sign Algorithm을 활용해서 해당 정보를 sign함
3. Signed Information을 string 형태로 보내게 된다. (매우 긴 text)

종류

1. Access Token
   • 실제로 권한을 얻을 때 사용하는 토큰 (개인정보, 이메일 등에 접근할 때 사용)
2. Refresh Token
   • Access Token의 유효기간이 만료됐을 때, Refresh Token을 사용해서 새로운 Access Token을 발급받음

Request

1. 클라이언트가 id, pw를 통해 로그인 요청
2. 서버에서 확인 후 Session ID와 비슷하게 Signed Info 혹은 Token을 전달
3. 클라이언트는 Access Token을 가지고 있다가 서버에 전송
4. 서버에서 토큰을 받으면 해당 토큰의 유효성 검증
5. 토큰이 유효하다면 유저로 인증

장점

• Session과 다르게 DB를 생성할 필요가 없다.
• 서버가 이중, 삼중일 경우 Session보다 장점을 가진다.
  수십, 수백대의 서버의 경우 load balancing으로 인해 유저가 처음 방문시 1번 서버에 Session이 있지만 2번 서버로 방문하게 되면 Session 정보가 없다.
  ⇒ Redis Session 통합을 하거나 JWT로 구현

단점

• 암호화 되어있지 않다. (누구나 해당 컨텐츠를 확인 가능)

---

Session vs JWT

Session

• 로그인된 모든 유저의 정보를 저장
• 해당 정보를 통해 기능 추가 가능
  • 특정 유저 추방 (강제 로그아웃)
    → 해당 세션 삭제
• Session을 위한 DB가 필요하다
  • 주로 Redis를 사용

JWT

• 생성된 토큰 추적 X
• 서버는 토큰의 유효성만 검증
• DB 필요 X
• ex) QR 체크인이 JWT임

References

• https://www.youtube.com/watch?v=tosLBcAX1vk
• https://velog.io/@shitaikoto/Web-Auth-Token
• https://nesoy.github.io/articles/2017-03/Session-Cookie