Skip to content

Latest commit

 

History

History
76 lines (57 loc) · 4.8 KB

Cookie,Session,Token.md

File metadata and controls

76 lines (57 loc) · 4.8 KB

쿠키 세션 토큰

쿠키

  • 쿠키를 이용해 서버는 브라우저에 데이터를 넣을 수 있음
  • 이용자를 기억하기 위해서
  • 사이트 방문 시 브라우저는 서버에 요청을 보냄 ⇒ 서버는 이에 응답 : 응답(모든 데이터와 이용자가 찾는 페이지 정보 + 브라우저에 저장하고자 하는 쿠키)
  • 브라우저에 쿠키 저장한 후 해당 브라우저에 재접속할 때마다 브라우저는 쿠키도 같이 요청보냄.
  • 쿠키는 도메인에 따라 제한
  • 쿠키는 유효기간이 존재 : 서버가 정한 기간에 따라 존재

ex) 웹사이트 언어 설정 : 쿠키에 언어 정보 저장 : 이후 접속에 이 정보 재 전송

세션 vs 토큰

  • 프로토콜을 stateless
    • 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄짐
    • 요청끼리 연결 없고, 메모리 없음
    • 요청 후에는 이용자에 대한 정보를 잊음.
    • 세션을 통해서
    • 서버는 들어오는 쿠키를 보고 세션 ID와 함께오는 쿠키를 확인 함. 뭔지는 모르고 세션 ID를 가지고 세션 DB 를 확인 → 여기서 해당 ID는 유저가 누구인지 알게 됨.
    • 해당 요청이 끝나고 다른 페이지로 ㅇ동하면 위 일련의 과정이 반복됨
    • 중요한 유저 정보는 모두 서버에 존재
    • 유저가 갖고 있는 것은 세션 ID 뿐임
    • 쿠키 → 세션 ID를 전달하기 위한 매개체일 뿐
    • 쿠키는 브라우저에만 존재함 (네이티브 앱 X)
    • 세션은 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장해야 함 ⇒즉, 요청이 들어올 때 마다 서버는 쿠키를 받아 세션 ID를 보고 세션 아이디와 일치하는 유저를 찾아야지 다음 일을 할 수 있음 즉, 유저가 늘어남에 따라 DB가 들어나야함 ⇒ JWT로 유저 인증 처리하면 세션 DB가 없어도 되고, 서버는 유저 인증을 위한 일을 안해도 됨 .
  • 토큰
    • 네이티브앱에서 쓰는 세션
  1. 유저명 Nico가 로그인 할 때 아이디 비번이 맞으면 서버는 DB를 만들지 않고 유저의 ID를 가져다가 (에를 들면) 사인 알고리즘으로 사인해 사인된 정보를 string 형태로 보냄
  2. 보통 세션 ID보다 훨씬 길다.
  3. 쿠키는 공간 제약이 있지만 JWT는 없음

동일하게 로그인했는데 DB 건드리는대신 정보를 사인하고 전달하는 것이다임

서버에 요청을 보내려면 세션 id와 비슷하게 사인된 정보 혹은 토큰을 서버에 보내야함. 서버는 토큰을 받으면 해당 사인이 유효한지 체크 ( 토큰 조작 여부 확인)

세션 ) 그냥 세션 ID만 주면 됨. 세션에 대한 모든 정보는 세션 DB에 저장되어 있기 때문에 페이지를 요청하면. 서버는 세션 ID를 DB에서 찾으면 됨

JWT ) 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장 ⇒ 해당 토큰을 우리에게 전달

페이지 요청시 서버는 해당 토큰의 유효성만 검증하면 됨. DB 거치는 것 없이

JWT는 암호화되지 않음 따라서 누구나 열어서 해당 컨텐츠를 볼 수 있ㅇ음. 비밀정보흫 JWT에 두면 안됨.

토큰을 사인하고, 유효성을 검증한다는 것

세션과 JWT의 장점과 단점은?

  1. 세션 사용시
    1. 서버는 로그인 된 유저의 모든 정보 저장
    2. 해당 정보를 이용해 새로운 기능 추가 가능
      1. 특정 유저를 쫓아내고 싶을 때 → 세션을 삭제하기
      2. 로그인된 모든 디바이스를 보여주고, 원하지 않는 디바이스 로그아웃 시키기
      3. 넷플릭스 처럼 계정 공유 숫자 제한
        1. 로그인 몇명이 했고 언제 했는지 알 수 있음..
    3. 서버에 누가 로그인 했는지 저장했고, 세션 DB가 있기 때문
    4. DB를 사고, 유지해야 함. 유저 증가 시 DB 증설 필요 주로 redis 사용
  2. JWT 사용시
    1. 생성된 토큰을 추적하지 않음
    2. 서버가 아는 것은 토큰의 유효성뿐.
    3. DB 구매 필요 없음. ⇒ DB가 하는 일들 수행 불가
    4. 데이터 사인하고 유저에게 보내고 해당 데이터를 돌려받을 때 , 유효성 검증이 가능 ⇒ DB 없이 모든 게 가능함
      1. 코로나 QR코드는 JWT가 들어가있음! 사용 사례가 많다.
      2. 그 중 1이 세션 DB 없이 유저 인증하기
    5. JWT 인증의 제약만 잘 알아두자
    6. 서비스가 커지고, 유저 계정을 더 잘 관리하고자 한다면 세션이 더 유용

마지막 정리

쿠키 ⇒ 그냥 옮기는 시스템, 즉 매개체

토큰 ⇒ 서버가 기억하는 이상하게 생긴 텍스트, ID 카드 처럼 서버에게 보여줘야 하는 것

JWT ⇒ 정보를 갖고 있는 토큰 DB없이 검증 가능. 유저 인증을 위해서 JWT 혹은 세션 사용 가능