쿠키 vs 세션 vs 토큰

Sujin Lee·2022년 2월 23일
0
post-thumbnail

❓🧐 로그인 기능을 구현하던 중 개념이 헷갈려서 찾아보게 됨

✏️ 쿠키(Cookie)

  • 서버는 쿠키를 이용해 브라우저에 데이터를 넣을 수 있다.

  • response: 모든 데이터와 함께 사용자가 찾던 페이지 정보, 브라우저에 저장하고자 하는 쿠키

  • 브라우저에 쿠키를 저장한 후 해당 웹사이트를 방문할 때마다 브라우저는 해당 쿠키와 함께 서버에 요청

  • 쿠키는 도메인에 따라 제한됨
    - 유튜브가 준 쿠키는 유튜브에만 보내짐

  • 쿠키는 서버가 정한 유효기간이 있다.

  • 쿠키는 인증뿐만 아니라 여러가지 정보를 저장
    - 웹 사이트의 언어 설정을 영어에서 한국어로 바꾸면 서버는 쿠키에 해당 설정을 저장해서 보냄
    - 다음에 해당 웹 사이트를 방문할 때 쿠키는 요청과 함께 서버로 보내지고, 서버는 쿠키가 기억해둔 언어 설정의 페이지를 제공


    세션토큰이 왜 필요한지 이해하기 위해서는 웹 사이트를 이용할 때 쓰는 프로토콜(HTTP)은 stateless 라는 것을 알아야함!

✏️ stateless

  • 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄진다는 뜻
  • 요청끼리 연결이 없음. 메모리가 없음 ➞ 요청이 끝나면 서버가 나를 잊어버림
  • 그래서 요청할 때마다 우리가 누군지 알려줘야 함 ➞ 그 방법 중 하나가 세션

✏️ 세션(Session)

  • 'sugenius'라는 유저명이 있고, 로그인 하고 싶다면 유저명과 비밀번호를 서버로 보냄

  • 비밀번호가 맞다면 서버는 세션DB에 'sugenius'라는 유저를 생성
    - 해당 세션에는 별도의 ID가 있음
    - 해당 세션ID쿠키를 통해 브라우저로 돌아오고 저장됨
    (세션DB에 유저가 저장되어있음)
    (세션ID를 서버에 줌)(해당 세션ID쿠키를 통해 브라우저로 보냄)

  • 따라서 같은 웹 사이트의 다른 페이지로 이동하면 브라우저는 세션ID를 갖고있는 쿠키를 서버에 보냄
    - 쿠키는 자동으로 보내지니까 서버는 세션ID와 함께 오는 쿠키를 알지만 우리가 누구인지는 아직 모름
    - 해당 세션ID를 가지고 세션DB를 확인할 것이고 거기에 해당ID는 유저명 'sugenius'의 것이라는 걸 알게 되고 그제서야 서버는 우리가 누군지 알게 됨
    - 해당 요청이 끝나고 다른 페이지로 이동하게 되면 이 모든 프로세스가 반복됨
    - 중요한 유저 정보는 모두 서버에 있다는 것!
    - 유저가 갖고있는 것은 세션ID

  • 쿠키는 그저 세션ID를 전달하기 위한 매개체일뿐

  • 세션을 이용해 iOS, Android 앱을 만들 수 있지만 쿠키는 사용 못함 (쿠키는 브라우저에만 있음) 바로 이 경우 토큰을 사용

  • 현재 로그인한 유저들의 모든 세션ID를 DB에 저장해야함

  • 해당 토큰을 서버에 보내고 서버는 세션DB에 해당 토큰과 일치하는 유저를 찾음
    - 즉 요청이 들어올 때마다 서버는 쿠키를 받아서 세션ID를 보고 세션ID와 일치하는 유저를 찾고 그제서야 다음 작업을 수행 ➞ 유저가 늘어남에 따라 DB리소스가 더 필요한 것 ➞ 이때 JWT가 등장

✏️ 토큰(Token)

  • 토큰은 그냥 이상하게 생긴 string ㅋㅋ
  • JWT는 토큰 형식으로 JWT로 유저 인증을 처리하면 세션DB를 갖을 필요가 없고 서버는 유저 인증한다고 많은 일을 하지 않아도 됨
  • 로그인 예시를 통한 JWT와 세션의 차이점
    1. 유저명 'sugenius'가 로그인 하려면 유저명, 비밀번호를 서버로 보냄
    2. 유저명, 비밀번호가 맞다면 서버는 DB에 뭔가를 생성하지 않음
    3. (예를 들면) 대신 서버는 유저ID를 가져다가 사인 알고리즘을 이용해 사인을 함
    4. 해당 사인된 정보를 string형태로 보냄
  • 보통 세션ID보다 훨씬 길다 (쿠키는 공간 제약이 있고, JWT는 제약이 없음)
  • 서버에 요청을 보내려면 세션ID와 비슷하게 해당 사인된 정보 혹은 토큰을 서버에 보냄 ➞ 서버는 토큰을 받으면 해당 사인이 유효한지 체크하고 (토큰을 조작햇는지 체크) ➞ 토큰이 유효하다면 서버는 우리를 유저로 인증

✏️ 세션과 JWT의 비교

  • 세션에서는 서버에서 그냥 세션ID만 주면 됨 세션에 대한 모든 정보는 세션DB에 저장되어있음. 페이지를 요청하면 서버는 세션ID를 DB에서 찾으면 되는 것
  • JWT에서는 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장 그리고 해당 토큰을 우리에게 줌. 페이지를 요청하면 서버는 해당 토큰이 유효한지만 검증하면 되는 것 DB를 거칠 필요 없음.
  • JWT는 암호화 되어있지 않음 누구나 열어서 해당 컨텐츠를 볼 수 있음
    - 비밀정보를 JWT안에 두는 건 안됨

📍 세션 장단점

  • 세션을 사용하면 서버는 로그인 된 유저의 모든 정보를 저장하기 때문에 해당 정보를 이용하면 새로운 기능들을 추가할 수 있음 👍
    - 예를 들면 특정 유저를 쫓아내고 싶을 때 세션 삭제해버리면 됨
    - 인스타그램처럼 로그인된 모든 디바이스를 보여주는데 원하지 않는 디바이스를 강제 로그아웃
    - 넷플릭스처럼 계정 공유 숫자를 제한 (현재 로그인 몇명, 시청중인지?)
  • 이 모든건 세션DB가 있기 때문 근데 이렇게 다 알고 싶으면 DB를 사고 유지해야 함 👎
    - 이를 위한 DB로는 주로 Redis를 사용: 해당 목적을 수행하기 위한 빠르고 저렴한 DB

📍 JWT 장단점

  • DB를 따로 살 필요가 없음 👍
  • 강제 로그아웃 같은 기능 할 수 없음 (해당 토큰이 만료되기 전까지는 유효하니까) 👎
  • DB없이 데이터를 사인해서 유저에게 보내고 해당 데이터를 돌려받을 때 유효성을 검증할 수 있음 👍
    - 예를 들어 QR코드
  • 생성된 토큰을 추적하지 않음. 서버가 아는 것은 토큰이 유효한가 여부일 뿐
  • 서비스가 커지고 유저의 계정을 잘 관리하고 싶다면 그때 세션으로 옮기는건 어떠한지?

⭐️ 결론

쿠키 = 그냥 옮기는 시스템. 매개체
토큰 = 서버가 기억하는 이상하게 생긴 텍스트, ID카드처럼 서버에게 보여줘야 하는 것
JWT = 정보를 갖고있는 토큰, DB없이 검증할 수 있음

  • 유저 인증을 위해서 JWT 혹은 세션을 사용할 수 있음

참고
https://youtu.be/tosLBcAX1vk

profile
공부한 내용을 기록하는 공간입니다. 📝

0개의 댓글