cookie, session, jwt

cookie

• 쿠키를 이용해서 서버는 우리의 브라우저에 데이터를 넣을 수 있다. - 데이터를 넣는 이유는, 클라이언트의 정보를 기억하기 위해서!
• 브라우저는 서버에 요청을 보내고, 서버는 이에 응답할텐데, 응답에는 모든 데이터와 클라이언트가 찾던 페이지 정보가 있다.
  • 이때 응답에 쿠키도 포함함!
• 브라우저에 쿠키를 저장한 후, 해당 웹사이트에 방문할 때마다, 브라우저는 해당 쿠키를 요청과 함께 보내게 된다.
• 쿠키는 도메인에 따라 제한이 된다.
  • ex) 유튜브가 준 쿠키는 유튜브에만 전송이 된다.
• 쿠키는 유효기간이 있다. (서버가 유효기간을 정함)
• 쿠키는 인증 뿐만 아니라, 여러가지 정보를 저장한다.

session과 token이 필요한 이유

• http프로토콜(클라이언트와 서버 사이 데이터를 전송하는 프로토콜)은 stateless하기 때문!
  • 그럼 비연결성은 무엇인데?
    • http의 경우, 한번 데이터 전송을 완료하면, 더 이상 연결이 지속되지 않는다.
    • 이전의 요청과 독립적으로 이루어진다는 뜻! (=내가 요청한 것에 대해 응답이 끝나면 서버는 나의 정보를 잊어버림!)
• 즉, 연결상태를 유지하지 않기때문에 어떤 클라이언트인지 알려줘야하는데, 이를 위한 방법으로 Cookie와 Session인 것!

Session동작방식

• 'Nico'라는 유저명이 있고, Nico가 로그인한다면,
• 유저명 + 비밀번호를 서버게 전송하게 된다.
• 비밀번호가 맞다면, 세션DB에 'Nico'라는 유저를 생성한다.
  • 세션DB에 'Nico'라는 유저를 저장할때, 특정 세션ID와 함께 부여된다.
• 해당 세션ID는 쿠키를 통해 브라우저로 저장이 된다.
• 이때, 내가 같은 웹사이트에 다른 페이지로 이동하게 되면, 브라우저는 세션ID를 갖고 있는 쿠키를 서버에 전송하게 된다.
  • 이때, 쿠키는 자동으로 전송이 되는것임!
• 서버는 세션ID와 함께 오는 쿠키를 확인하게 된다. (아직까지도 서버는 이 클라이언트가 누구인지 모름!)
  • 서버는 세션ID가 있는 쿠키를 지닌 요청만 알고 있지, 누구인지 모름!
• 해당 세션ID를 가지고 세션DB를 확인하게되고 이때, 해당 ID는 유저명 Nico의 것이라는 것을 알게된다.
• 이제서야, 서버는 클라이언트가 누구인지 깨닫고 'Nico, 환영합니다.' 와 같은 메시지를 응답한다.
• Session에서 가장 중요한 것은, 유저 정보는 서버에 있다는 것이다!
• 클라이언트가 가지고 있는 것은 세션ID일 뿐임!
• 쿠키는, 세션ID를 전송하기위한 하나의 매개체일뿐이다! (주머니같은 것이라고 생각하면 됨!)
• 세션은 IOS, Android에서 사용가능하지만, 쿠키는 웹브라우저에만 존재하기 때문에, IOS, Android에서 사용불가능!
• Native 앱에서는 token을 사용한다!

Token

• token은 string형태이다.
• 해당 token을 서버에 전송하고 서버는 세션DB에서 해당 토큰과 일치하는 유저를 찾게 된다.

Session단점

• 요청이 있을때마다, 세션DB에 있는 세션ID를 확인한 후, 클라이언트 정보를 알게 된다.
  • 즉, 요청이 있을때마다, DB에 접근해서 세션ID를 확인한다.
• 이렇게 되면, 사용자 수가 늘어남에 따라 DB리소스가 더 필요한 것이다.

Session장점

• 사용자 정보가 세션DB에 있기때문에, 특정 사용자를 내쫓아버리고 싶다면, 해당 세션ID를 삭제하기만 하면 된다.
  • 예) 인스타그램에서, 로그인된 모든 장치 중, 특정 장치에서 로그아웃하고 싶다면, 강제로그아웃이 가능함!
• 염두해야할 것은, 세션DB에 유저정보가 모두 있기때문에 세션DB를 사고 유지해야한다!
• 유저가 많아지면 많아질수록 DB도 커져야함! (이를 위한 용도가 바로 빠르고 저렴한 Redis!)

Session의 단점을 보완하기 위해 등장한 JWT!

• JWT는 토큰 형식이다.
• 요청할때마다 토큰을 서버에 전송한다.
• JWT장점
  • JWT로 유저인증을 처리하면, 세션DB를 갖을 필요가 없다.
  • 서버는 매 요청마다, 유저인증을 할 필요가 없다!

로그인을 통해 Session과 JWT의 동작방식의 차이를 알아보자.

• 유저명 Nico가 로그인을 하려면, 유저명, 비밀번호를 서버에 전송한다. (공통점)
• JWT
  • 유저명, 비번이 맞다면, 서버는 DB에 뭔가를 생성하지 않는다.
  • 대신, 서버는 유저ID(유저명)를 통해 사인알고리즘을 이용해서 사인하게된다.
  • 그리고 '사인된 정보'(=JWT)를 string형태로 클라이언트에 전송하게 된다.
  • 서버는 토큰을 받으면, 해당 사인(토큰)이 유효한지 확인한다.
  • 토큰이 유효하다면, 서버는 해당 클라이언트를 유저로 인증하게 된다. (유효한지 여부만 따짐!)
  • 쿠키는 공간제약이 있지만, jwt는 공간제약이 없기때문에 엄청 길어도 상관없음! 실제로도 jwt는 정보가 굉장히 김!
• 요약)
  • JWT
    • 세션DB를 가지지 않고, DB에 접근하는 대신, 서명하고 서명정보(jwt)를 클라이언트에 전송하는 것!
    • 해당 토큰(jwt)이 유효한지만 확인하면 된다.
    • 암호화된 정보가 아니다!
    • DB를 따로 살 필요가 없음!
    • 하지만, session장점에서 언급한 강제로그아웃은 불가능!
    • 예) 코로나를 통한 QR코드 인증
  • session
    • 세션ID를 요청함. 세션에 대한 모든 정보는 세션DB에 별도로 저장됨.