Cookie, Session, and Token
Cookie
쿠키를 이용해서 서버는 browser에 데이터를 넣을 수 있다 (사용자 정보를 기억하기 위해!)
브라우저는 서버에 요청을 보낼 때마다 해당 쿠키도 함께 보내게 된다
단, 쿠키는 도메인별로 제한된다 (유튜브가 준 쿠키는 유튜브에만 보내짐)
쿠키는 유효 기간이 있는데, 서버가 정한 기간에 따라 유효하다
쿠키는 인증 뿐만 아니라 여러가지 정보를 줄 수 있다
ex) 언어 설정
Session
HTTP는
stateless하다서버로 가는 모든 요청이 이전 요청과 독립적으로 다뤄진다
요청이 끝나면, 서버는 누가 요청했는지를 잊어버리게 된다
그렇기 때문에 우리는 요청할 때마다 누군지를 알려줘야한다
이렇게 하는 방법 중 하나가 바로 Session이다
Session의 동작 방식
로그인 시 서버는
Session DB에 해당 유저를 생성한다해당 session에는 별도의 ID가 있다
해당 session ID는 쿠키를 통해 브라우저로 돌아오고, 저장된다
웹사이트에서 페이지를 이동할 때마다 브라우저는 session ID를 갖고 있는 cookie를 서버에 보낸다
(쿠키는 자동으로 보내지니까~)
서버는 들어오는 쿠키를 보고, Session ID와 함께 오는 쿠키를 확인한다
서버는 해당 session ID를 가지고
session DB를 확인하여 해당 유저 정보를 알아내게 된다즉, 요청이 있을 때마다 session DB를 조회해야한다 (부하 발생 가능성 있음)
웹사이트 페이지를 이동하게 되면, 위의 전체 과정이 반복된다
기억해야할 것은,
중요한 유저 정보는 모두 서버에 있다는 점이다사용자는 session ID만을 가지고 있다
쿠키는 그저 session ID를 전달하기 위한 매개체일 뿐이다
session을 이용해 iOS, Android 앱을 만들 수 있지만, 쿠키는 브라우저에만 있기 때문에 사용할 수 없다
바로 이 경우,
Token을 사용한다!
JWT
JWT는 토큰 형식이다
JWT로 사용자 인증을 처리하면 session DB를 가질 필요가 없고, 서버는 사용자 인증을 위해 많은 일을 하지 않아도 된다!
동작 방식사용자가 서버에 로그인 정보를 보내고 해당 정보가 유효할 때, 서버는 DB에 무언가를 생성하지 않는다
그 대신 서버는 사용자의 ID를 가져다가
Sign 알고리즘을 이용해서 사인한다그리고
Signed Info(Token)를 string 형태로 사용자에게 보낸다사용자가
Signed Info를 서버로 보내면, 서버는 해당 사인(토큰) 이 유효한지 체크하고, 토큰이 유효하다면 서버는 사용자로 인증한다
JWT는 보통 session ID보다 훨~씬 길다
왜냐면 cookie는 공간 제약이 있기 때문이다
JWT는 공간 제약이 없어서, 엄청 길어도 된다
Session과 Token의 차이점
Sessionsession에선 서버가 그냥 session ID만 주면 된다
session에 대한 모든 정보는 session DB에 저장되어 있다
서버는 요청이 올 때, session ID를 DB에서 조회하면 된다
JWTJWT에선 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장한다
해당 토큰을 사용자에게 준다
사용자가 페이지를 요청하면, 서버는 해당 토큰이 유효한지만 검증한다
Session과 Token의 장단점
Session서버는 로그인 된 유저의 모든 정보를 저장한다
해당 정보를 이용하여, 새로운 기능들을 추가할 수 있다
특정 유저를 쫓아내고 싶을 때, session을 삭제해 버리면 된다
넷플릭스는 계정 유저 개수 제한 (4명 넘으면 강제 로그아웃)을 session DB를 이용해서 한다
JWTJWT를 사용하면, 생성된 token을 추적하지 않는다
서버가 아는 것은, 토큰이 유효한가 여부일 뿐이다
JWT로 인증하면 session DB가 필요 없지만, 강제 로그아웃 등의 기능을 할 수는 없다
해당 토큰이 만료되기 전까지는 유효하기 때문이다
Last updated