Cookie, Sesiion, Cache, Web Storage🤔

1. 인증(Authentication) & 인가(Authorization)👻

• 인증 : 자신을 인증할 요소를 통해 특정 개체의 신원을 확인하는 과정
• 인가 : 특정 객체가 특정 리소스에 접근할 수 있는 지 혹은 특정 동작을 수행할 수 있는 지 확인하는 과정

---

2. HTTP 프로토콜 특징👾

1. Connectionless(비연결 지향) : 요청에 맞는 응답을 보낸 후 연결을 끊는 처리 방식
2. Statless(무상태) : 클라이언트와 서버 간의 connection을 끊은 후에는 상태 정보를 유지하지 않는다.

💡 Stateful의 필요성 : HTTP의 Connectionless, Statless 특징에 의해 이전 통신에서 주고 받은 데이터를 다음 통신에서 사용하지 못하게 되는데 실제 서비스를 살펴보면 이전 데이터들이 현재 통신을 처리하는데 필요한 경우가 많다. 예를 들어 회원용 API(ex. 장바구니 내역 확인 등)를 클라이언트가 호출 시 매번 클라이언트가 누구인지 인증을 해줘야 한다는 번거로움이 생긴다. 이러한 문제를 해결하기 위해 쿠키와 세션이 등장하였다.

---

3. 쿠키(Cookie)란?🍪

클라이언트가 특정 웹사이트에 접속 할 때 서버가 클라이언트의 상태 정보를 클라이언트의 로컬 pc에 저장하는 기록 정보 파일을 ‘쿠키’라고 부른다.

• 쿠키 특징
  • 이름, 값, 만료일, 경로 정보로 구성되어진다.
  • 4KB 정도의 저장 공간을 지닌다
  • session cookie와 persistent cookie로 구분된다.
    • session cookie : 만료일이 없고 브라우저나 탭이 열려 있는 동안에만 저장됨
    • persistent cookie : 만료일을 지닌 채 디스크에 저장되어 브라우저가 닫혀도 유지된다.
  • 매 요청 시 서버에 전달 되므로 크기가 클 경우 서버에 부담이 갈 수도 있다.
  • 유효 기간이 존재한다.(서버가 결정)
  • 세션 키 값을 지녀 서버가 클라이언트를 구분할 수 있도록 한다.
  • 문자열만 저장 가능하다.
  • 도메인에 국한된다.
    • 유튜브가 보내준 쿠키는 유튜브에만 보내지게 된다.
  • 요청 시 쿠키의 값을 그대로 보내 보안에 취약하다.
  • 브라우저간 쿠키 지원 형태가 달라 브라우저 간 공유가 불가능하다.
• 쿠키 동작 과정
  1. 클라이언트가 웹 사이트에 접근
  2. 웹 서버가 쿠키 생성
  3. 응답을 보낼 때 생성한 쿠키를 함께 클라이언트에게 전달
  4. 쿠키를 클라이언트가 로컬 pc에 저장하고 있다가 추후에 다시 서버에 요청을 보낼 때 쿠키를 함께 전달
  5. 브라우저를 껐다가 다시 키고 동일 사이트 재방문 시 클라이언트의 로컬 pc에 쿠키가 남아있다면 요청 시 쿠키를 함께 전달한다.
• 예시
  • 로그인 자동 완성
  • “오늘 하루 이 창을 다시 보지 않기” 팝업을 체크하면 서버가 쿠키 정보를 확인하여 팝업을 띄우지 않는다.

---

4. 쿠키 속성🍪

• Http 헤더에 쿠키에 대한 속성을 지정한다.
  • Set-Cookie : 클라이언트에게 쿠키를 저장하라고 지정, 만료 날짜를 지정할 수 있다.
  • Cookie : 쿠키를 클라이언트가 저장, Http 요청 시 서버로 전달

{
  Set-Cookie:
		b_cookie=butter;
    Expires=Sat, 11 Feb 2023 16:35:00;
		Domain=naver.com;
		Path=/users;
		Secure;
    HttpOnly;
  ]
}

• Name: 쿠키 이름(b_cookie)
• Value: 쿠키에 저장된 값(butter)
• Expires & Max-Age : 쿠키의 만료 기간을 설정
  • Expires(날짜와 시간) 또는 Max-age(초)를 사용하여 만료 기간을 명시한다면 Permanent Cookie가 되고 그렇지 않다면 Session Cookie가 된다.
  • expires="Wdy, DD−Mon−YYYY HH:MM:SS GMT”
  • 만료 시간은 서버가 아닌 클라이언트를 기준으로 계산된다.
  • Expires와 MaxAge 모두 사용했다면 MaxAge가 우선 시 된다.
• Domain: 쿠키가 전송되는 도메인을 지정(스코프 지정)
  • 스코프에 현재 위치와 서브 도메인 모두 포함
    • news.naver.com / email.naver.com 과 같이 naver.com의 서브 도메인 또한 요청 시 쿠키를 서버에 전송하도록 지정
  • 지정한 domain 값이 탐색 중인 도메인과 일치하지 않을 경우 브라우저에서 거부 한다. ⇒ 이를 통해 특정 도메인에서 다른 도메인에 대한 쿠키를 사용하지 못하도록 한다.
• Path : 쿠키 스코프를 도메인 내 특정 경로로 제한
  • path에 지정한 값을 포함한 하위 경로로 요청할 때만 쿠키를 전송
  • ex. /Users ⇒ /Users를 포함한 경로일 때만 쿠키 전송
• Secure : Https 프로토콜에서만 쿠키를 전송
  • 스니핑으로부터 안전성 증가
• HttpOnly : 자바스크립트의 Document.cookie 객체를 통해 쿠키의 접근을 제한

---

5. 세션(Session)🤖

일정 시간 동안 동일한 클라이언트로부터 오는 요청들은 하나의 같은 상태(단위)라 보고 그 상태를 유지 시키는 기술을 ‘세션’이라고 부른다. 이때 일정 시간을 결정하는 기준은 브라우저가 웹 서버와 연결 되기 시작한 순간부터 끝날 때 까지 이다.(웹 서버의 저장되는 쿠키라고 생각)

• 세션 특징
  • 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장
  • 저장 데이터의 제한이 없다
  • 클라이언트 마다 고유 session id를 부여한다.
  • 스니핑 당해도 정보가 세션 ID만 탈취당하기 때문에 보안이 쿠키 인증 방식 보단 좋지만 해커가 탈취한 세션 ID로 클라이언트인 척 위장할 수 있다.
  • 세션은 유저 정보를 서버에 저장하고 있기 때문에 부가 기능들을 유저에게 제공할 수 있다.
    • 넷플릭스 5명까지 인원 추가
    • 인스타그램 로그인 된 기기 확인 및 수정
    • 강제 로그아웃 가능
  • 세션DB는 주로 redis를 사용(빠르고 저렴)
• 세션 동작 과정
  1. 클라이언트가 웹 사이트에 접근
  2. 서버가 접근한 클라이언트의 쿠키를 확인하여 session id가 있는지 확인
  3. session id가 없다면 서버가 생성하여 클라이언트에게 전달(생성된 session id는 session db에 저장)
  4. 클라이언트가 쿠키를 사용하여 받은 session id를 쿠키 or 로컬 스토리지에 저장
  5. 웹 사이트에 재접속 시 요청과 함께 쿠키에 저장된 session id를 전달
  6. 서버는 클라이언트로부터 받는 쿠키 내 세션 ID에 따라 세션 DB를 확인 후 사용자의 데이터(아이디 or 패스워드)를 읽는다.
• 서버에서 세션 정보 삭제 방법
  • 사용자가 로그아웃 버튼 클릭 시
  • 클라이언트로 부터 특정 시간 동안 요청이 없을 경우 자동 로그아웃(세션 삭제)
• 예시
  • 한 사이트 내에서 여러 페이지를 이동해도 로그인 상태가 유지 되는 것

💡 쿠키와 세션은 함께 사용하여 동작한다!!!! ⇒ 쿠키를 통해 세션 ID를 클라이언트와 서버가 주고 받기 때문에

---

6. Cookie인증과 Session인증의 차이😵‍💫

1. 사용자의 정보 저장 위치 : 쿠키는 클라이언트의 측에 저장되고 세션은 서버에 저장된다.
2. 보안 : 쿠키는 클라이언트의 로컬 PC에 저장되기 때문에 데이터가 변질될 수 있으며 쿠키 인증 방식을 사용할 경우 스니핑 당하면 클라이언트의 개인 정보가 그대로 노출되지만 세션 인증을 사용하면 스니핑 당할 경우 session id만 노출되어 비교적 보안성이 높다.
3. 라이프 사이클(Life Cycle) : 쿠키는 로컬 pc 내에 저장되기 때문에 브라우저를 닫아도 유지될 수 있으며 따로 만료 기간을 지정할 수 있다. 반면 세션 또한 만료 기간을 지정할 순 있지만 클라이언트가 브라우저를 닫게 되면 세션 정보 또한 만료 기간에 상관 없이 사라지게 된다.

---

7. 캐시(Cache)란?👽

이미지, CSS, JS, 배너와 같이 변경 사항이 크지 않고 자주 사용 되는 데이터들(정적 파일)의 임시 저장소를 ‘캐시’라고 부른다. 클라이언트가 특정 웹 사이트에 첫 번째 요청 시 서버의 응답을 클라이언트의 로컬 PC 내 존재하는 캐시에 저장 후, 추후 요청 시 서버에 접근하는 것 대신 캐시에 접근하여 수행 속도를 증가 시킨다.(가방의 앞주머니 역할)

• 캐시 특징
  • 저장 공간이 작다
  • 비싸다
  • 서버에 접근하지 않고 사용자의 로컬 pc를 거치기 때문에 속도가 매우 빠르다
  • 캐시 데이터의 유효 기간이 존재하여 서버의 데이터와 캐시 데이터의 불일치를 해결
  • 필요한 데이터가 캐시 내 존재할 경우 hit, 존재 하지 않을 경우 miss라고 부른다.
• 캐시 동작 과정
  • 클라이언트가 웹 사이트에 접근
  • 첫 번째 요청일 경우 서버로부터 전달 받은 응답을 캐시에 저장
  • 다시 요청을 보낼 때 서버가 아닌 캐시를 먼저 확인하여 캐시 내 응답에 필요한 데이터가 있는지 확인하고 있다면(cache hit) 캐시에서 데이터를 가져와 사용(속도가 빠름)
  • nignx 설치 할 때 캐시 지웠더니 잘 돌아갔던 이유가 캐시에는 예전 값을 불러와서 그랬었다.(앞으론 캐시를 지워 데이터 동기화를 시켜주자...!)

---

8. 웹 스토리지(Web Storage)란?🤔

HTML5부터 지원하는 클라이언트에 데이터를 저장하는 임시 저장소를 ‘웹 스토리지’라고 부르며 Local Storage와 Session Storage로 구분된다.

• 웹 스토리지 특징
  • 쿠키와 달리 서버에 실제로 전송되지 않고 명시적으로만 전송되어 서버의 부담이 적다.
  • 필요한 경우에만 꺼내 쓸 수 있어 쿠키와 달리 자동 전송의 위험성이 없다.
  • 다른 도메인에서 특정 도메인의 데이터를 요청할 수 없다.(CSRF 안전)
  • 4KB의 저장공간을 갖는 쿠키에 비해 웹 스토리지는 5MB의 정보를 저장 가능하다.
• Local Storage
  • 도메인 별로 생성되며 다른 도메인의 로컬 스토리지에는 접근 권한이 없다.
    • Domain : ip 주소는 사람이 기억하기 어렵기 때문에 기억하기 쉽도록 이름을 부여한 것
  • 데이터가 브라우저를 종료해도 영구적으로 남는다.
    • Javascript code로 삭제해야 한다.
  • 서로 다른 브라우저 탭이라도 같은 도메인일 경우 같은 로컬 스토리지를 사용한다.
  • ‘자동 로그인’, ‘검색 기록’과 같이 지속적으로 필요한 정보를 저장하기에 좋다.
• Session Storage
  • 브라우저 탭 단위로 생성된다.
  • 브라우저를 닫을 시 데이터 또한 사라지게 된다.
  • 동일한 탭이라도 다른 도메인이라면 또 다른 세션 스토리지를 사용한다.
  • ‘입력 폼(구글 폼)’과 같이 잠시 동안 필요한 정보를 저장하기에 좋다.
  • 비로그인 장바구니에 사용