Session VS Token VS Cookie

WOOK JONG KIM·2022년 12월 2일
0

궁금 저장소

목록 보기
3/5
post-thumbnail

쿠키를 이용해서 서버는 유저 브라우저에 Data를 넣을 수 있다

사이트 방문 시 브라우저는 서버에 요청을 보내게 된다

이때 서버는 response로 찾던 페이지정보 + Data + 쿠키를 추가해서 보낸다

서버 입장에서 쿠키는 브라우저에 저장하고자 하는 정보를 담아서 보냄

이렇게 브라우저에 쿠키가 저장된 후 유저가 해당 Website 방문 시 브라우저는 해당 쿠키도 Request와 함께 보냄

쿠키는 도메인에 따라 저장됨
-> ex) 네이버가 준 쿠키는 네이버에만 보내짐

또한 쿠키는 유효기간을 지니는데 이는 서버가 정함

쿠키는 인증 뿐 아니라 여러 정보 저장 가능

예를 들어 웹사이트의 언어 설정을 바꾸면 서버는 쿠키를 주고

선택한 언어를 저장

이후에 유저가 해당 웹사이트를 방문시 쿠키는 요청과 함께 서버로 보내지고 덕분에 서버는 쿠키가 기억해 둔 언어설정의 페이지 제공


Http , 즉 웹사이트를 이용할 때 쓰는 프로토콜은 stateless

-> stateless란 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다루어 짐
-> 요청끼리 연결이 없다(메모리가 없다)

요청이 끝나면 서버는 유저가 누군지 잊어버릴 것!
-> 요청할때 마다 유저는 스스로 자신이 누군지 알려줘야 함
-> 이를 하는 방법 중 하나가 세션을 이용하는 것


Session

Aaron이라는 유저명이 있고, 로그인이 하고싶다면
-> 유저명과 비밀번호를 서버에 보냄

이때 비밀번호가 맞다면, 서버는 세션Db에 Aaron이라는 유저를 생성할 것

해당 세션에는 별도의 Id가 있다

해당 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장된다!!

따라서 같은 웹사이트의 다른 페이지로 이동하려면 브라우저는 세션ID를 가지고 있는 쿠키를 서버에 보낼 것(쿠키는 자동으로 보내짐)

서버는 들어오는 쿠키를 보고, 세션Id와 함께 오는 쿠키를 확인할것
-> 아직까지도 서버는 유저가 누구인지 모름
-> 단지 세션 ID가 있는 쿠키를 지닌 요청이 있다는 것만 알뿐!

서버는 해당 세션 Id를 가지고 세션 DB를 확인할 것이고

이때 해당 ID는 유저명 Aaron의 것이라는 걸 알게됨(서버가 유저가 누구인지 알게됨)

해당 요청이 끝나고, 다른 페이지로 이동하게 되면 앞선 모든 프로세스가 반복됨

중요한 유저 정보는 모두 서버에 있는 반면, 사용자는 세션 ID만 가지고 있다

쿠키는 Session ID를 전달하기 위한 일종의 매개체

세션을 통해 Android나 ios앱을 개발할 수는 없지만 , 쿠키는 사용할 수 없다(브라우저에만 있기 때문)
-> 이 경우 사용하는 것이 토큰


Token

토큰은 이상한 String 형태로 되어 있음

토큰을 서버에 보냈을 때 서버는 세션 Db에서 해당 토큰과 일치하는 유저를 찾음

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

즉 요청이 들어올때 마다 서버는 쿠키를 받아서, 세션 Id를 보고 세션Id와 일치하는 유저를 찾아야함
-> 요청이 있을때마다 Db를 뒤져야 함
-> 유저가 늘어나면, Db리소스가 더 많이 필요

JWT

토큰형식, JWT로 유저 인증을 처리 하면 세션DB를 가질 필요가 없고 서버가 유저 인증한다고 많은 일을 하지 않아도 됨

토큰은 서버에서 받은 후, 요청 할 때마다 보내야 하는 것

세션,JWT 둘다 Aaron이 로그인을 하려면 서버에 아이디와 패스워드를 보내야 함

JWT는 세션과 다르게 서버에서 DB에 뭔가를 생성하지 않음

대신 서버는 예를 들어 유저 아이디를 가져다가 사인알고리즘을 통해 사인을 하게 됨 -> 해당 사인 정보를 String 형태로 보냄

쿠키보다 훨씬 긴형태의 String

로그인 이후 다른 페이지를 접속하기 위해 서버에 요청을 보낸다면 세션 ID와 비슷하게 해당 사인된 정보 또는 토큰을 서버에 보내야 함

서버는 토큰을 받으면, 해당 사인이 유효한지 체크하고, 유효할 시 서버는 우리를 유저로 인증할 것

JWT에서 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장(DB X)
-> 그리고 해당 토큰을 유저에게 줌

이후 페이지 요청 시 서버는 해당 토큰이 유효한지만 검증하면 됨

JWT는 암호화가 되지않았고, 누구나 열어서 볼 수 있음(비밀번호 두면 X)


세션,JWT 장단점

세션을 사용하면 서버는 로그인 된 유저의 모든 정보를 저장하게 됨

이 정보를 이용하면 새로운 기능 추가 가능
ex) 특정 유저 강제로 쫓아내기 위해 세션 삭제
로그인된 모든 디바이스 보여주기, 넷플릭스 처럼 계정 공유 숫자 제한

DB를 사고 유지하기 위해 돈이 많이 듬
-> 주로 Redis 사용

JWT를 사용하면, 생성된 토큰을 추적하지 않음
-> 서버가 아는것은 토큰의 유효 여부
-> Db를 따로 살필요는 없지만 강제 로그아웃 같은 기능 불가(토큰이 만료되기 전까지는 유효하기에)

ex) QR 코드 인증

Reference

https://www.youtube.com/watch?v=tosLBcAX1vk&t=123

profile
Journey for Backend Developer

0개의 댓글