쿠키

쿠키: 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용되고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 파일

단점

• 보안에 취약하다. (요청 시 쿠키의 값을 그대로 보내어, 유출 및 조작당할 위험이 존재한다.)
• 용량 제한이 있어, 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기에, 브라우저 간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다

쿠키를 활용한 로그인 방식

• 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
  (쿠키는 Key-Value 형식의 문자열이다.)
  
• 이후 해당 클라이언트는 요청을 보낼 때마다 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
  
• 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별할 수 있다.

---

세션

세션: 비밀번호 등 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다

서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 인증 정보는 서버에 저장하고, 클라이언트 식별자인 JSESSIONID를 쿠키에 담는다.

이후 클라이언트는 요청을 보낼 때마다 JSESSIONID쿠키를 함께 보낸다.

그리하면 서버는 JSESSIONID의 유효성을 판별해 클라이언트를 식별한다

장점

• 서버가 클라이언트의 웹 브라우저에 의존하지 않아도 된다.

• 쿠키를 포함한 요청이 외부에 노출되어도 세션 ID 자체는 유의미한 개인 정보를 담지 않는다.

• 각 사용자마다 고유한 세션 ID가 발급되기 때문에, 요청이 들어올 때마다 회원 정보를 확인(로그인)할 필요 없다.

• DB를 기반으로 공유 계정의 수를 제한시키거나, 사용자의 로그인을 제한시키는 등의 기능을 만들 수 있다.

단점

• 해커가 세션 ID를 중간에 탈취하여 클라이언트인 척 위장할 수 있다.
• 서버에서 세션 저장소를 사용하기 때문에, 요청이 많아지면 서버에 부하가 생긴다.

세션을 활용한 로그인 방식

• 사용자가 로그인을 위해 유저명, 비밀번호를 보내고, 비번이 맞다면 유저별 세션DB 공간을 만든다.
  

• 각 세션에는 별도의 ID가 있으며, 해당 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장된다
  

• 따라서 같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션 ID를 가지고 있는 쿠키를 서버에게 보내고, 서버가 ID를 기반으로 세션 DB를 확인해 유저가 누구인지 알게된다.

  • 중요한 유저 정보가 모두 서버에게 있고, 유저는 세션 ID만 갖는다.
  • 쿠키는 세션 ID를 전달하기위한 매개체

쿠키는 브라우저에만 존재하기 때문에 IOS, Android에서는 쓸수 없음
→ 토큰을 이용