인증과 관련하여 쿠키가 localStorage보다 선호되는 이유

원본 글 / https://dev.to/leduc1901/why-cookie-is-preferable-compared-to-localstorage-when-it-comes-to-authentication-48mb?utm_source=oneoneone 

 

참고한 글 / https://velopert.com/2389 ([JWT] JSON Web Token 소개 및 구조)

https://www.rfc-editor.org/rfc/rfc7519 (rfc/rfc7519 표준에 대한 문서)

https://jwt.io/ (jwt.io 는 브라우저 상에서 jwt 를 검증해주고, 생성할 수 있게 해주는 디버거)

https://ko.javascript.info/cookie

https://ledgku.tistory.com/72 , https://velog.io/@denmark-choco/Web-Authentication%EC%9D%B8%EC%A6%9D(세션과 쿠키에 대한 설명. 세션이 왜 생겼나 - http 프로토콜이 stateless, connectionless해서~의 내용)

https://javascript.info/localstorage (sessionStorage와 비교)

---

글이 던지는 주제

RFC7519 웹표준으로써, Json Web Token(이하 JWT) 사용되는 경우에

(보통 인증이다. 사용시, 서버측에서는 유저의 세션을 유지할 필요가 없다. 유저의 로그인 여부를 신경쓸 필요가 없고, 요청시 토큰만 확인하면 되므로 -> 세션관리 필요x, 서버자원 아끼기 good!

- 정보를 안정성 있게 전달할 때 사용되는 양식이다.

- 여러 언어에서 지원한다. C, Java, Python, JS, Ruby, Go... 대부분의 언어!)

- self-contained. 즉 자기자신이 필요한 모든 정보를 지니고 있다는 뜻. 이미 검증되어있다는 signature역시 포함 한다. 위 블로그 글에는 자가수용적. 이런 어휘로 널리 번역되는듯 한데 -_- ;; 자족적인, 자립? independent? 완비 된? 의 뜻으로 더 설명이 잘 될것같다.

not requiring help or support from anyone or anything else, complete by itself 

대체 왜 이렇게 어려운 어휘를 쓰는건지...;;; 이유있대도 싫네...

- 웹서버의 경우, http 헤더에 넣어 전달하는 등, 전달이 용이함!)

front-side에서 저장은 어디에 하면 좋을까?(즉 어떻게 관리하면 좋을까? 의 측면)

 

갑분 네이버 감성

 

이 글에서는 쿠키와 LocalStorage를 비교한다.

그런데 이 글의 댓글을 보니, Iron-session도 있길래 이것까지 함께 비교해보고자 한다. 

 

	Cookie	LocalStorage	Iron-session
특징	쿠키는 브라우저에 저장되는 작은 크기의 문자열 RFC 6265 명세에서 정의한 HTTP 프로토콜의 일부 주로 웹서버에 의해 만들어지겠죠 쿠키나 세션이 없다면, 게시판이나 메일을 확인할때마다, 페이지이동 시 마다 로그인을 해야합니다.		Node.js stateless session utility
	작지만 강력	많이 저장. 브라우저 껐다 켜도 살아있음.	~ 아직 파악중 ~
방식	document.cookie = "cookieName=value" Set-Cookie: <cookie-name>=<cookie-value> 서버가 응답헤더에 Set-Cookie에 내용을 넣어 전달 * 꼭 인코딩 해야합니다. secure 옵션 설정시, https로 통신하는 경우에만 쿠키가 전송된다. 원래 쿠키는 도메인만 확인, 프로토콜 따지지 않아서... 그래서 이런 옵션이 있는 것. 그 외 samesite 옵션 설정도 가능한데, 구식브라우저 대응 어렵다.    * 서브도메인에서 쿠키에 접근가능하게 하려면, 이렇게 설정 -> domain=site.com	localStorage.setItem("yourTokenName", yourToken)  localStorage.getItem("yourTokenName", yourToken)	사실... JWT 방식이 아니다.
용도	클라이언트 식별 용도	예를들면, 이런 식으로 사용자가 적은 글 보관할 때. localStorage 사용할 수 있겠죠.	서명 및 암호화된 쿠키를 사용하여 데이터를 저장하는 Node.js 상태 비저장 세션 유틸리티
Pros	공격자가 사이트에서 js 실행하더라도, 쿠키에서 토큰읽기 불가 만료 기한 설정 가능 path 지정가능(보통은 웹사이트의 모든 페이지에서 쿠키에 접근할 수 있도록 하죠)	백엔드 필요없다. 크게 저장 가능. 5mb(1600characters or 10images로 치환가능) 만료 안된다.  브라우저 다시시작해도 살아남는다. (localStorage) same origin 간에  모든 탭과 창 간에서 공유된다.	세션을 위한 백엔드를 구축하지 않아도 된다 JWT는 암호화되지 않는다.
Cons	4kb 용량 교차 사이트 요청 위조(csrf)공격에 취약  세션 하이재킹 가능 쿠키(FE):세션(BE) 서버에서 추가적인 저장공간이 필요해	xss공격에 취약. localStorage에 저장된 액세스토큰을 get할 수 있어서 발생하는 취약점.	JWT는 서로다른 시스템 간 원활한 통신을 보장한다. (https://github.com/vvo/iron-session#how-is-this-different-from-jwt) 그래서 JWT Encryption JWE를 사용하라는 공식 리포지토리의 문서. 아니 그럼 JWE를 쓰지 왜 iron-session을 쓰나? 뭐 편한가? 쩝..
Cons 극복방법	sameSite플래그  안티 csrf토큰 사용
그 외	서드파티 쿠키는 브라우저에 따라 동작이 다르다.  Safari는 일절 불가 Firefox는 서드파티 쿠키 set하는 도메인을 블랙리스트로 만들어 차단한다.
	GDPR 유럽연합의 사용자 개인정보 보호를 강제하는법령 -> 그래서 유럽 지사의 웹사이트 방문시, 이런거 설정할때가 많죠. 귀찮지만 올바른 방법이라고 생각합니다.

결론 / 쿠키는 여전히 약간의 취약점이 있지만, localStorage보다 선호된다. 용도에 따라 달리 사용한다. (길이에 비해 허무한 결론)

 

 

세션 / 서버와 클라이언트의 연결이 활성화 된 상태.

서버상에서 정보가 관리되는 경우를 세션 : 브라우저의 메모리에서 관리하는 정보를 쿠키