session과 token이 필요한 이유
위 두개를 알기전에 이걸 이해해야한다..
HTTP. 웹 사이트를 이용할 때 쓰는 프로토콜. 해당 프로토콜은 stateless임.
stateless란, server로 가는 모든 request가 '독립적'이다는 뜻이다.
(request가 끝난다면 server는 너가 누군지 모른다.
=== 요청 할 때마다 우리가 누군지 알려줘야한다.)
이 방법중의 하나가 'Session'이다.
ex) '황의혁' + '****' 데이터를 => server에 보냄.
만약 비밀번호가 일치한다면, session DataBase에 '황의혁' 이라는 유저를 생성한다.
해당 session에서는 별도의 ID가 존재한다.
해당 session ID는 쿠키를 통해 브라우저로 돌아오고 저장됨.
그래서 같은 홈페이지에서의 다른 page로 이동 시 browser는 세션 ID를 가지고 있는 쿠키를 서버에 보낸다.
서버에서는 세션ID와 쿠키를 확인한다. 이 때 까지 서버는 우리가 누구인지 모른다.
해당 세션ID를 가지고 세션DB를 확인한다.
해당ID는 유저명 '황의혁'이라는 것을 알게된다. 이 때 서버는 우리가 누군지 안다.
중요한 정보는 모두 서버에 있다는 것. 유저가 가지고 있는건 '세션ID' 다.
즉, 쿠키는 그저 세선 ID를 전달하기 위한, 매개체이다.
쿠키는 android나 ios에서는 없다. 바로 이 경우 token을 사용한다.
해당 토큰을 서버에 보내고 서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾는다.
session의 point는, 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장해야한다는 것이다.
즉, 요청이 들어올 때마다 서버는 쿠키를 받아서, 세션 ID를 보고 DB에서 일치하는지 확인하는 작업이 필요하다는 것.
유저가 늘어나면 그만큼 DB에 대한 resource가 필요하다는 것이다.
JWT의 두두둥장
'토큰 형식'의 JWT
특징 : session DB를 가질 필요없다.
서버는 유저 인증한다고 일 많이 안해도된다.
session vs JWT
'황의혁' + '**' 라는 데이터를 server에 보낸다.
여기까지 둘의 차이점은 없다.
유저명과 비번이 맞다면, 서버는 DB에 뭔가를 생성하지 않아.
대신 서버는 유저의 ID를 가져가다 사인을 함.
그리고 해당 '사인된 정보'를 string 형태로 보낸다.
그게 JWT 임. 'asdlfkja;ldfjwoeijf2334lksdlfkjsldfjlajd'이런식으로 길게 보내짐
DB를 건드리는 대신에 정보를 사인하고, 전달하는 것이 다인 'JWT'.
'JWT'가 서버에 요청을 보내려면 세션 ID와 비슷하게, 토큰을 서버에 보내야한다.
서버는 토큰을 받으면 유효한지 체크한다.
토큰이 유효하면 유저로 인증한다.
세션에선 그냥 세션 ID만 주면됨.
세션에 대한 모든 정보는 세션 DB에 저장되어있음.
JWT에선 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장한다.
그리고 우리에게 토큰을 줌
페이지를 요청하면, 서버는 해당 토큰이 유효한지만 검증하면 된다.
DB를 거칠필요 ㄴㄴ
JWT는 암호화 된게 아니다.
누구나 열어서 해당 컨텐츠 볼 수 있음.
비밀정보를 JWT에 두며 안됨.
장점 단점
세선 서버는 로그인 된 유저의 모든 정보를 저장
새로운 기능들을 추가할 수 있게된다.
예를 들어 특정 유저를 쫓아내고 싶을때, 그냥 세션정보를 삭제해버리면 된다.
예시)넷플릭스 로그인 세션 DB가 있기 때문에 가능하다..
이를 위해선 DB사고 유지해야함. 유저가 늘어나면 디비도 커져야함 보통 Redis를 사용
JWT 생성된 토큰을 추적 ㄴ
서버가 아는 건 유효한지 아닌지만
강제 로그아웃 불가능.
토큰이 만료되기 전까지 추방 ㄴㄴ
디비없이 모든게 가능
예시)qr 체크인
유저계정을 좀 더 관리잘하고 싶으면 세션으로 갈아타는게 맞다.
쿠키 = 그냥 옮기는 시스템, 매개체
토큰 = 서버가 기억하는 이상하게 생긴 텍스트 카드 처럼 서버에게 보여줘야하는 것임
jwt = 정보를 갖고있는 토큰 DB없이 검증 가능
참고자료 : https://youtu.be/tosLBcAX1vk
