오늘은 브라우저의 저장소에 대해 학습을 해보겠다!!

보통 필자는 Local storage를 자주썼다. 사용하기 간편하고 클라이언트에서 영원한 저장이 가능하기 때문에 뭔가 안정감을 느꼈다. 하지만 보안상 좋지는 않을것이라 늘 생각했었는데, 이번 기회를 통해 Browser Storage에 대해 학습해보겠다🔥

Browser Storage ❓

일단 브라우저는 저장소의 기능을 제공한다.

3가지의 저장소가 있다.

LocalStorage, SessionStorage,Cookie

각각을 한번 살펴보자

Web Storage ❓

먼저 Web Storage는 LocalStorage, SessionStorage가 있다.

Web Storage는 다음과 같은 특징을 갖는다.

1. 서버의 전송이 없고 클라이언트에서 저장이 된다.
2. 객체정보를 저장할 수 있다.
3. 용량이 큰 편이다.

LocalStorage vs SessionStorage ❓

LocalStorage는 먼저 영구적 저장이 가능하다. 세션이 종료되어도(페이지가 꺼져도) 웹 브라우저는 이 기록을 저장한다. 또,
도메인마다 다른 LocalStorage를 가질 수 있다.

SessionStorage는 세션이 종료되면(페이지가 꺼지면) 웹 브라우저는 이 기록을 제거한다.

Cookie ❓

쿠키는 브라우저 저장소 중 하나로 4KB의 용량을 가진 텍스트 조각이라고 보면된다. 그니깐 포춘쿠키를 보면 작은 종이 쪼가리에 오늘의 운세가 적혀있지 않은가?? 그와 비슷하다!

클라이언트단 즉 브라우저는 해당 쿠키를 생성할 수 있다. 아니 이미 저장소는 있고 그 저장소라는 쿠키에 내용을 적어 저장할 수 있다.

이는 용량이 작을 뿐더러 만약 쿠키가 생성이 되었다면 서버와 통신을 하는 HTTP 요청마다 쿠키가 전송되어 네트워크에 무리가 갈 수 있다.

사실 무리가 간다는 것에는 잘 모르겠다. 그 작은 데이터 조각이 보내져도 이를 처리하는데 무리가 간다는 것일까?

궁금한 건 chat gpt에게!

그렇다..! 필자가 많은 고객을 다루는 웹 서비스를 진행해본 경험이 없어 그 가늠을 하지 못했을 뿐 만약 1억명이 사용하는 웹 사이트가 있다면 쿠키에 대한 전송과 검증이 많이 일어난다면 ?? 분명 서버에는 큰 부담이 될 것이다.

그래서 그런지 웹 브라우저는 한 사이트당 20개의 쿠키를 제한해 두었다.

쿠키의 구성요소 ❓

쿠키의 구성 요소
1. 이름: 각각의 쿠 키를 구별하는 데 사용되는 이름
2. 값: 쿠키의 이름과 관련된 값
3. 유효시간: 쿠키의 유지시간
4. 도메인: 쿠키를 전송할 도메인
5. 경로: 쿠키를 전송할 요청 경로

쿠키의 목적 ❓

세션 관리 : 서버가 알아야될 정보 ( 로그인 및 사용자 정보 , 접속시간 )
개인화 : 사용자에 맞는 페이지 제공
트래킹 : 사용자 행동 및 패턴 분석

즉 쿠키는 사용자를 구분할 수 있는 데이터 조각이다. 사실 서버와 통신할 때 서버는 어떤 사용자인지 알기 힘들다. 서버는 요청을 받으면 전달해줄뿐 클라이언트를 구분해 특정짓지 못한다. 이를 해결하기 위해 쿠키를 사용할 수 있는 것이다!!

그렇기 때문에 로그인을 할 때 session, JWT등의 방식으로 클라이언트를 식별하고 이에 맞는 페이지를 제공할 수 있는 것이다.

출처

중요핵심 ⭐️

서버는 클라이언트를 특정하기 힘들고 이를 알아보게하기 위해 로그인을 하는 것이다.

로그인을 하는 방식에는 Session, JWT 방식등이 있다.

Session vs JWT ❓

로그인을 하는 방식 , 즉 서버가 클라이언트를 식별하게 하는 방식은 크게 2가지가 있다.

바로! Session과 JWT 방식.

참고한 유튜브

Session은 다음과 같이 인증할 수 있다.

Session ❗️

1. 사용자가 ID와 비밀번호를 입력하여 로그인을 시도한다.
2. 서버는 사용자가 입력한 ID와 비밀번호를 DB에서 확인하고 있다면, 인증이 성공, 새로운 세션을 생성한다.
3. 세션 ID를 생성하고 사용자와 연관된 데이터(사용자 정보, 권한 등)를 세션에 저장한다.
4. 세션 ID와 함께 사용자에게 응답을 보내어 클라이언트(브라우저)에 저장하도록 한다. 대표적으로 쿠키에 세션 ID를 담아서 보내는 방식이 사용됩니다.
5. 클라이언트는 다음 요청 시마다 저장된 세션 ID를 쿠키에 담아 요청 메시지에 포함하여 서버에 전송한다.
6. 서버는 클라이언트로부터 받은 세션 ID를 사용하여 세션 데이터를 조회하고 사용자를 인증합니다. 이를 통해 사용자의 상태를 확인하고 권한을 관리합니다.

그럼 2~3번에서 세션이 새롭게 형성되는데 어떻게 서버가 클라이언트를 특정하고 기억하게 할 수 있냐는 ?? 질문을 할 수 있다.

세션이 형성될 때 세션ID와 유저ID를 묶어서 저장하면 유저를 특정지으면서 로그인했는지를 확인할 수 있다.

정리하자면 다음과 같다 🔥
ID, PW 로그인 정보 맞네? => 세션 생성, 세션 ID생성 => 세션 ID를 쿠키에 담아 클라이언트에 보낼게 => 이제 요청할 때마다 해당 쿠키를 검사하겠지 => 쿠키 검사가 통과되면 ID에 맞는 개인화면을 볼 수 있을 거야

JWT ❗️

1. 사용자가 로그인 폼에 ID와 비밀번호를 입력한다.
2. 서버는 입력된 ID와 비밀번호를 확인하고, 인증이 성공하면 사용자 정보를 기반으로 JWT를 생성한다.
3. JWT에는 사용자 정보와 토큰 유효 기간 등이 포함된다. 또한, JWT에 서명을 추가하여 토큰의 변조를 방지합니다.
4. 서버는 생성된 JWT를 사용자에게 HTTP 응답으로 보내준다.
5. 클라이언트(브라우저)는 받은 JWT를 저장소(보통은 쿠키나 로컬 스토리지)에 저장한다.
6. 클라이언트는 이후의 모든 요청에서 저장된 JWT를 헤더나 파라미터에 포함하여 서버에 전송한다.
7. 서버는 클라이언트가 보낸 JWT를 받아와서 유효성을 검증한다. JWT의 서명을 확인하여 토큰이 변조되지 않았는지 검증한다.
8. 토큰이 유효하다면, 서버는 토큰에 포함된 사용자 정보를 확인하여 사용자를 인증한다/.
9. 클라이언트의 요청을 처리하고 응답을 보낸다.

즉, JWT 방식은 DB가 필요없다. JWT를 발행하면 클라이언트는 이를 받고 서버와 통신할 때 이에 대한 유효성만 검증받으면 된다.

하지만 보안상 취약점을 보이는데
만약 시크릿 key를 해커가 유추하는경우
JWT토큰을 디코딩하여 원래 JWT를 유추하는경우 등이있다.

Session방식은 DB를 사용해야하고 서버에서 부담이 늘어난다(DB도 조회하고 찾아야하고..) 반면 JWT 방식은 유효성만 검사하면되고 DB도 필요없기 때문에 트래픽이 높은 사이트에 알맞을 수 있다.

또 Session은 SessionID를 주고받는 반면 JWT는 암호화된 중요정보를 주고받는다.

정리

이렇게 LocalStorage, SessionStorage, Cookie를 정리하면서 각 로그인 방식(서버야 나좀 알아봐줘 방식)인 Session, JWT까지 알게되었다. 오늘부터 개인프로젝트의 Develop을 시작할건데 이에도 참 많은 도움을 받을 수 있을 거 같다. 무엇보다 또 프론트엔드 개발자에게 꼭 필수인 로그인 방식을 알게되어서 개운한 느낌이 들고 자신감도 생긴다 ❗️