세션 / 토큰 / JWT / 쿠키

영상 참고

쿠키

서버가 브라우저에 데이터를 전달할 수 있게 해주는 매개체

1. 사이트 방문 시 브라우저 - 서버간 통신이 발생

   • 서버는 사용자가 찾는 데이터, 페이지 정보가 담겨있는 응답과 브라우저가 저장하고자 하는 쿠키 함께 전달함.

2. 사용자가 브라우저에 쿠키를 저장하면 브라우저에 접속할 때마다 브라우저는 해당 쿠키와 함께 서버에 요청을 보내게 됨.

   • 쿠키는 도메인에 따라 제한이 됨.
     ex. 유튜브가 준 쿠키는 유튜브에만 보내지게 됨.
   • 쿠키는 유통기한이 있음(서버가 정한 기간에 따라 다름)
   • 쿠키는 인증뿐만 아니라 여러가지 정보를 저장할 수 있음
     ex. 언어설정 변경 시 변경한 언어설정을 기억

세션/토큰

• 세션과 토큰이 필요한 이유
  • http 웹사이트를 이용할 때 쓰는 프로토콜은 stateless
    • stateless ? 서버에게 전달되는 요청이 과거의 요청과 독립적으로 다뤄짐(요청 간 연결이 없음)
  • 요청을 할 때마다 누군지 알려줘야 하는데 그 방법 중 하나가 세션.

세션

• ryan 라는 유저가 올바른 로그인 정보를 서버로 보내면 서버는 세션 DB(ex. 브라우저)에 ryan라는 유저를 생성.

  • 세션에는 별도의 id가 있는데, 이 id는 쿠키를 통해 브라우저로 전송되고 저장.

  • 따라서 같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션ID를 가지고 있는 쿠키를 서버에게 전송.

    1) 쿠키는 자동으로 전송되기 때문에 서버는 서버로 전송되는 (세션ID가 들어있는)쿠키를 확인.
    2) 발견한 세션id를 통해 세션DB를 확인
    3) 세션 id의 사용자가 ryan라는 것을 알게 됨.

  • 다른 페이지로 이동해도 같은 프로세스가 반복.

  • 중요한 점은 중요 유저 정보는 모두 서버에 있음. 유저가 가지고 있는 것은 세션id뿐임.

  • 세션db는 현재 로그인한 유저들의 모든 세션id를 db에 저장해야 되며 동시에 요청이 들어올 때마다 서버는 쿠키를 받아서 세션id를 보고 일치하는 유저를 찾아야 함.

    • 유저가 늘어날 때마다 db리소스가 늘어난다는 문제가 있음

토큰

• 쿠키는 브라우저에만 있고 네이티브 앱에는 없기 때문에 이 경우 토큰을 사용함
• 토큰(문자열)을 서버에 보내고 서버는 세션 db에서 해당 토큰과 일치하는 유저를 찾음.

JWT

• 토큰 형식. JWT로 인증을 하면 세션DB를 갖을 필요도 없고 서버는 많은 작업을 안해도 됨.
• JWT는 세션DB와 다르게 로그인 정보를 서버에 보내도 DB에 무언가를 생성하지 않는 대신 서버는 받은 유저의 로그인 검증 정보를 유저에게 다시 전송함.
• DB를 건드리는 대신 정보를 인증하고 전달하는 것이 전부
• JWT는 서버에 요청을 보내려면 검증된 로그인 정보 또는 토큰을 서버에 보내야 함.
• 서버는 토큰을 받으면 사인이 유효한 지 확인하고 유효하다면 서버는 사용자를 유저로 인식함

세션 / JWT 차이점 / 장단점

세션

• 세션ID만 주면 됨, 세션에 대한 모든 정보는 세션 DB에 저장되어 있음.
  페이지를 요청하면 서버는 세션ID를 DB에서 찾기만 하면 됨.

JWT

• 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장함. 그리고 토큰을 유저에게 줌. 페이지를 요청하면 서버는 토큰이 유효한지만 검증하면 됨. DB를 거칠 필요가 없음.

세션 vs jwt 장점

세션

• 서버는 로그인 된 유저의 모든 정보를 저장하는 세션DB가 있기 때문에, 정보를 활용하여 새로운 기능을 추가할 수 있음. (특정 유저 밴하고 싶으면 세션 삭제 / 넷플릭스처럼 계정 공유 숫자를 제한할 수 있음)

jwt

• 토큰이 유효한지만 확인하면 되기 때문에 db를 따로 살 필요 없음
• 데이터를 사인하고 유저에게 보내고 데이터를 돌려받을 때 유효성을 검증할 수 있음 db없이 모든 것이 가능함.(qr코드도 jwt)