쿠키, 세션, 토큰 정리

---

쿠키 ✔️

서버가 클라이언트 (브라우저)에게 일방적으로 주는 것

 

HTTP Response (응답코드, 헤더, 바디 중 헤더에 set-cookie)

각 옵션의 의미

domain: 같은 사이트
path: 같은 경로 / 
httpOnly: 자바스크립트 사용 여부
maxAge, Expires: 만료 기간 설정 
sameSite: 3rd-cookie
LAX: 3rd-party가 GET일 때만 허용
STRICT: 3rd-party 쿠키 차단
none: 적용 안함 (https일 때만 가능)
secure: HTTPS에 쿠키를 전달 여부

 

쿠키의 인증 상 한계

MaxAge or Expires, HttpOnly, SameSite 등 각종 옵션들을 이용해 XSS, CSRF 등의 공격에 대비할 수 있는 방법이 있기는 하지만
결국은 클라이언트에 정보를 저장하기 때문에 인증 상 한계가 존재

 

세션에서 로그아웃의 중요성  ✔️

 

세션 아이디가 담긴 쿠키가 유출된 상태에서는 해당 쿠키를 이용한 요청이 유출된 쿠키를 이용한 공격인지
정말로 사용자가 요청을 보낸건지 서버는 확인할 방법이 없다.

즉 서버에서 세션을 파괴하는 과정이 반드시 필요하다.

 

로그아웃 하는 방법 2가지

1. 서버 세션 스토어에 있는 세션을 지운다.(destroy) 클라이언트에서 세션 아이디를 없앤다.
2. 서버 세션 스토어에 있는 세션을 지운다.(destroy) 서버에서 클라이언트가 가진 세션아이디를 빈 문자열, 랜덤값으로 바꾼다.

 

세션과 비교해서 토큰의 장점은 무엇이 있을까? ✔️

	설명	접속 상태 저장은 어디에?	단점
쿠키	쿠키는 그저 http의 stateless한 것을 보완해주는 도구이다.	클라이언트	쿠키 그 자체는 인증이 아니다.
세션	접속 상태를 서버가 가진다(stateful) 접속 상태와 권한 부여를 위해 세션 아이디(토큰)을 쿠키로 전송한다.	서버	하나의 서버에서만 접속상태를 가지므로 분산에 불리하다.
토큰 방식(jwt가 대표적)	토큰 자체가 무결성(integrity)을 증명할 수 있다. 서버가 접속 상태를 갖고 있지 않아도 된다. (stateless)	클라이언트(쿠키, localStorage,in-memory)	모든 요청에 토큰을 실어 보내야 하는 점
OAuth 2.0	제3자로부터 인증을 대행하고, access token을 받는다. 인증을 대신할 뿐, 권한관리는 토큰 방식과 유사하다.	클라이언트(쿠키, localStorage,in-memory)	모든 요청에 토큰을 실어 보내야 하는 점

 

인증과 인가 (권한 관리, 허가) 차이 ✔️

 

인증
-> 사용자가 유효한지 판단(자격 증명) Ex. 버스에 탈 수 있게 해주는 것: 버스카드 / JWT

인가
-> 어떤 권한을 획득할 수 있는지 결정 Ex. OAuth

---