1. 세션, 토큰, 쿠키

쿠키

- 쿠키를 이용해서 서버는 '나'의 브라우저에 데이터를 넣을 수 있음 -> '나'에 관한 것을 기억하기 위해서

- 사이트에 방문하면 브라우저는 서버에 요청을 보냄 -> 서버가 응답

- 응답에는 모든 데이터와 찾던 페이지 정보가 포함되어 있음 (브라우저에 저장하고자하는 쿠키도 있을 수 있음)

- 쿠키를 브라우저에 저장한 후, 해당 웹사이트에 접속할 때마다 브라우저는 해당 쿠키도 요청과 함께 보내게 됨.

- 쿠키는 도메인에 따라 제한되며 유효기간(서버가 정한 기간)이 있음

- 인증 뿐만 아니라 여러가지 정보를 저장할 수 있음(ex. 언어설정 유지)

---

stateless - 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄진다는 뜻 (요청끼리 연결이 없어 메모리가 없음)

-> 요청이 끝나면 서버는 우리가 누군지 잊어버리게 됨

-> 요청할 때마다 우리가 누군지 알려줘야 함

 

이를 하는 방법 중 하나가 세션(Session)

---

세션

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

-> 비밀번호가 맞다면 서버는 세션 DB(별도의 ID가 있음)에 'a' 라는 유저를 생성하게 됨

->  해당 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장됨

 

같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션 ID를 갖고있는 쿠키를 서버에 보냄(자동)

-> 서버는 세션 ID와 오는 쿠키 확인 (세션 ID가 있는 쿠키를 지닌 요청이 있다는 것만 알뿐 아직 서버는 우리가 누군지 모름)

-> 세션 ID를 가지고 세션 DB를 확인하고 거기서 해당 ID가 유저명 'a'의 것이라는 걸 알게됨(누군지 알게됨)

-> 해당 요청이 끝나고 다른 페이지로 이동하게 되면 이 모든 프로세스 반복

 

cf) 중요한 유저 정보는 모두 서버에 있음 ! -> DB 유지비용 필요

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

---

세션을 이용해 iOS, Android 앱을 만들 수 있지만 쿠키는 브라우저에만 있기 때문에 사용할 수 없음

-> 이 경우 토큰(Token) 사용!

---

토큰 : string이라고 보면 됨

 

세션 vs JWT

세션 : 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장해야함, 요청이 들어올 때 마다 서버는 쿠키를 받아서 세션 ID를 보고 세션 ID와 일치하는 유저를 찾아야 다음 작업 수행 가능 -> 요청이 있을때마다 DB를 찾아야함 -> 유저가 늘어남에 따라 DB 리소스가 더 필요 

해당 토큰을 서버에 보내고 서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾음

 

JWT : 토큰 형식. 필요한 정보를 토큰에 저장하기 때문에 JWT로 유저 인증을 처리하면 세션 DB를 갖을 필요 X -> 서버가 유저 인증을 위해 많은 일을 하지 않아도 됨! 암호화되지 않아서 누구나 볼 수 있음

 

서버는 토큰을 받으면 해당 사인이 유효한지 체크하고 유저로 인증함

---

조건부 렌더링 :특정 조건에 따라 다른 결과물을 렌더링 하는 것

리다이렉팅 : 사용자가 처음 요청한 URL이 아닌, 다른 URL로 보내는 것