🌼 Cookie, Session, Token, JWT

• 서버가 클라이언트 인증을 확인 하는 방식
• Cookie, Session의 보안하는 방식에서 JWT등장
• 기초적인 인증방식부터 공부하고, JWT 방식을 사용하는 이유를 알아보겠음

1️⃣ Cookie

• {key/value}의 형식의 문자열 이다.
• 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 정보 파일
• 각 사용자마다 고유정보 식별이 가능하다.

🐶 Cookie 인증 흐름

1. 클라이언트가 서버에 요청
2. 서버가 응답을 보낼때, Set-Cookie에 담아 보내면, 클라이언트에 저장을 할 수 있다.
3. 이후 클라이언트의 요청을 보낼때 마다, 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
4. 서버는 쿠키에 담긴 정보를 보고, 어떤 사용자인지 식별이 가능하다

⛔️ Cookie 인증 단점

1. 클라이언트 요청시 쿠키의 값 그대로 응답해주기 때문에 해킹 당하기 쉽게 노출된다 -> 보안에 취약
2. 용량 제한 -> 많은 정보를 담을 수 없다.
3. 브라우저간 공유 불가능
4. 사이즈가 커질수록 네트워크 부하가 심해진다.

2️⃣ Web Storage

• 클라이언트에 데이터를 저장할 수 있는 새로운 자료구죠
• {key/value}로 데이터를 저장, key로 데이터를 조회
• Localstorage(영구저장소) & Sessionstorage(임시 저장소)로, 데이터의 지속성을 구분
• Cookie와는 다르게 서버로 전송되지 않는다.
• 웹 스토리지 객체는 도메인·프로토콜·포트로 정의된 오리진(origin)

🐶 Localstorage

• 브라우저나 컴퓨터를 재식작해도 데이터가 삭제되지 않는다.
• 오리진이(도메인·프로토콜·포트) 같은 경우 데이터는 모든 탭과 창에서 공유가 된다.

🐶 Sessionstorage

• 현재 있는 탭 내에서만 유지된다.
• 같은 페이지라도 다른 탭에 있으면 다른 곳에 저장된다.
• 페이지를 새로 고침할 때 저장된 데이터는 보존 되지만, 탭을 닫고 새로 열 때는 삭제된다.

3️⃣ Session

• 클라이언트의 민감한 인증 정보를 서버측에서 저장하고 관리한다.
• 메모리에 저장하기도 하고, 데이터베이스에 저장하기도 한다.
• 민감한 정보는 응답값으로 줄지 말지 제어할 수 있다.
• {key : SESSION ID :{value}} 구성되어 있다.

🐶 Session 인증 흐름

1. 로그인을 하게 되면 세션이 서버에 저장된다. -> SESSION ID (세션의 식별하기 위해)
2. 브라우저 쿠키에 SESSION ID를 저장
3. 브라우저는 모든 요청을 Request에 Session id를 쿠키에 담아 요청
4. 브라우저에서 보내준 Session id와 서버측 Session id를 비교해 인증절차를 수행

⛔️ Session 인증 단점

1.Cookie와는 다르게 브라우저 측에서 중요한 정보는 담지 않고 있다.
2. 하지만, 해커가 Sessoin id를 탈취하여 사용할 수 있다.

4️⃣ JWT

• 토큰(Token)기반 인증 방법
• 토큰은 클라인언트에 저장되어, 서버에 부담을 덜 수 있다.(서버 입장 -> 메모리 할당 X)
• 인증에 필요한 정보들을 암호화 시킨 JSON토큰
• JWT 토큰을 HTTP 헤더에 실어 클라이언트를 식별 한다.

🐶 JWT 구조

• (.)을 기준으로 Header(헤더), Payload(내용), Signature(서명)를 의미한다.
• Header는 JWT 사용할 타입,해시 알고리즘의 종류
• Payload 사용자의 권한 정보와 데이터
• Signature는 Header,Payload를 Base64 URL-safe Encode를 한 이후
• Header에 명시된 해시 함수를 적용, 개인키로 서명한 전자 서명
  

JWT토큰 발급 : 공식문서

☃️ JWT을 사용하는 이유

• 별도의 저장소가 따로 필요없다.
• 기본 정보와 검증됬음을 증명한 모든 필요한 정보를 자체적으로 가지고 있다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능
• DB조회를 안해도 된다.즉, JWT는 토큰이 만료되었을때만 저장소에 접근하기 때문에 접근하는 횟수 자체는 훨씬 적다.

⛔️ 문제점

• 정보가 많아질수록 토큰 길이가 길어져 네트워크에 부하를 줄 수 있다.
• Payload를 탈취 당할 우려가 있으므로 중요한 정보는 넣지 말아야 한다.
• 토큰 자체를 탈취당하면 대처하기가 어렵기 때문에,
• Refresh Token & Acces Token이중으로 나누워 인증을 해야한다.

5️⃣ Refresh Token & Acces Token

• Access Token은 접근에 관여하는 토큰, Refresh Token은 재발급에 관여하는 토큰의 역할

🐶 Access Token

• 클라이언트가 서버에 요청을 보내면 해당 토큰에 있는 정보를 기반으로 응답

🐶 Refresh Token

• Access Token을 발급해주기위해 사용
• 토큰의 기한을 짧게 설정한다. 보통 데이터베이스에 유저 정보와 같이 기록

• Access Token이 탈취되면 토큰이 만료되기 전 까지, 토큰을 획득한 사람은 누구나 권한 접근이 가능해지는 문제점
• 유효 기간이 짧을 경우 그만큼 사용자는 로그인을 자주해야 한다.
• Refresh Token 활용하여 토큰을 이중 장막을 쳐서 보다 보안을 강화

참조 1
참조 2