[🌐 네트워크] Cookie와 Session 그리고 JWT

HTTP 특성

HTTP는 stateless, connectionless 특징을 가지고 있어 요청에 대한 응답을 처리하게 되면 연결을 끊어버린다. 

따라서 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않다. 

연결을 계속 유지한다면 이에 따른 자원 낭비가 심해지기 때문이다. 

 

하지만 상태가 남아있지 않아 서버는 클라이언트를 식별할 수 없는 단점이 있다. 

로그인을 하더라도 다음 요청에서 해당 클라이언트를 기억하지 못하므로 다시 로그인을 해야하는 문제가 발생하는 것이다. 

 

이러한 비연결성과 무상태성 특징을 보완한 기술이 Cookie와 Session이다. 

 

 

Cookie

👉 클라이언트(웹 브라우저)에 저장되는 작은 데이터 조각

• Key-Value형식으로 저장되며 클라이언트가 요청을 보낼 때마다 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보냄
• 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트 식별 

 

🔹 단점 

• 보안에 취약
  • 브라우저에서 쿠키 값을 확인할 수 있어 유출 및 조작 위험 발생 
• 용량 제한이 있어 많은 정보 담지 못함
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저 간 공유 불가능 

 

 

 

 

 

 

Session

👉 웹 서버 측에 사용자의 상태 정보를 저장하는 방법

쿠키만을 이용해 사용자 인증을 구현한다면 쿠키가 유출, 조작될 수 있는 보안 문제가 발생한다. 
HTTP로 개인정보를 주고 받는 것은 위험하며 다른 사람들도 사용자의 비밀번호를 확인할 수 있기 때문이다. 

 

• 쿠키에 저장된 사용자 정보를 서버의 메모리에 저장
• Session은 인증정보를 쿠키에 저장하지 않고 사용자의 식별자인 JSESSIONID를 저장
• 생성된 id를 쿠키에 담아서 전달
• 브라우저를 종료하면 정보가 삭제됨 

 

 

 

 

세션/쿠키 기반 인증방식 

1. 클라이언트가 로그인을 위해 해당 정보를 서버에 전달
   
   
2. 서버는 정보를 읽어 사용자를 확인하고 로그인 성공 시 사용자를 식별할 수 있는 고유한 세션 ID를 생성하고 이를 메모리나 DB에 저장
   👉 저장하는 곳 = 세션 저장소. 주로 Redis를 많이 사용
   
   
3. 서버는 요청의 결과값으로 세션ID를 사용자에게 전달
   
   
4. 세션ID를 전달받은 사용자는 쿠키에 해당 값을 저장
   
   
5. 이후 다른 페이지 이동이나 사용자 인증이 필요할 때 헤더에 해당 쿠키를 실어서 전달
   
   
6. 서버는 쿠키를 받아서 세션 저장소에 저장된 쿠키(세션ID)인지 확인
   
   
7. 유효한 쿠키(세션ID)일 경우 요청받은 데이터 반환

👉 id, pw를 주고 받지 말고 인증 정보 자체(=세션ID)를 특정 세션 저장소에 저장하고, 이 값을 쿠키에 담아 클라이언트가 쿠키를 요청할 때마다 세션 저장소에 있는 정보와 동일하지 확인

📛 세션 사용할 때의 단점 

- 세션 저장소에 문제가 발생 시 인증 불가
- stateful하기 때문에 http의 장점 발휘 못함
- 세션 저장소를 사용하기 위한 비용 발생 
- 사용자가 많아질수록 메모리 차지 큼
- 매번 요청 시 세션 저장소 조회 

 

 

JWT (JSON Web Token)

👉 인증에 필요한 정보들을 암호화시킨 토큰으로, JWT(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트 식별

JWT = 서명된 토큰 

JWT 구조

• Header
  
  • 토큰 타입이나 서명 생성에 어떤 알고리즘이 사용되었는지 저장
• Payload
  • 토큰에 포함될 claim 정보를 key-value 형태로 저장
• Signature
  • header를 디코딩한 값 + payload를 디코딩한 값 👉 서버가 가지고 있는 개인키로 암호화

세션의 단점을 보완하기 위해 만들어진 JWT는 별도의 세션 저장소를 강제하지 않기 때문에 stateless함. 
signature를 통한 보안성을 갖추고 있음. 

📛 JWT의 한계

- base64 인코딩을 통한 정보를 전달하므로 전달량이 많음 👉 네트워크 전달 시 많은 데이터 양으로 부하 발생 가능
- payload에 암호화가 되어 있지 않아 민감 정보 저장 X
- 토큰이 탈취당하면 만료될 때까지 대처 불가능 👉 Sliding Session 또는 Refresh Token으로 해결 

 

🔹 Sliding Session  

• 사용자가 활동하는 동안 세션을 지속적으로 연장

 

🔹 Refresh Token 

• Access Token이 만료되면 Refresh Token으로 서버에게 새로운 Access Token을 발급하도록 요청 
• 서버는 Refresh Token을 받아 서버의 Refresh Token storage에 해당 토큰이 있는지 확인하고, 있다면 Access Token 생성하여 전달 

 

 

참고 자료 

https://brunch.co.kr/@jinyoungchoi95/1

https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/