[TIL] 230115 JWT, 쿠키, 세션

프론트엔드는 백엔드의 고객이고, 사용자는 프론트엔드의 고객이다. 
백엔드 자료 ➜ 프론트엔드 유저 배포 ➜ 유저

01. JWT, 쿠키, 세션?

• HTTP : 인터넷상에서 데이터를 주고받기 위해 서버 및 클라이언트 모델을 따르는 규약
  • 문제점
    • 사용자가 브라우저나 컴퓨터의 전원을 끄게 되면 연결 종료 후 상태 정보가 저장되지 않는다. 그렇게 되면 사용자에 대한 정보가 없기 때문에 접속하는 사용자들을 새로운 사용자로 판단해 식별한다.
  • 해결 방법
    • 비연결성 / 비상태성을 보완해 서버가 클라이언트를 식별할 수 있게 해주는 쿠키/세션을 사용하는 것이다.
• 쿠키 : 웹에 접속할 때 생성되는 정보를 담고 있는 임시 파일이다. 서버를 대신해 사용자의 웹 브라우저(로컬)에 정보를 저장한다.
  • 사용자가 서버에 무언가를 요청할 때, 저장된 정보를 같이 보내 서버가 사용자를 식별할 수 있게 도와준다.
  • 목적 
    • 세션관리(로그인, 닉네임, 이메일, 접속시간, 장바구니 등 서버가 알아야 하는 정보를 저장)
    • 프라이빗한 개인화(사용자마다 다른 페이지를 뿌려줌)
    • 트래킹(사용자의 패턴 분석 및 기록 저장)
  • 단점
    • 하지만, 용량 제한이 있어 많은 정보를 담을 수 없음. 왜냐? 서버가 아닌 로컬에 저장되기 때문에 변조 및 위조로부터 취약함
• 세션 : 쿠키와 반대로 웹 브라우저(로컬)가 아닌 서버의 메모리에 세션 ID를 저장한다.
  • 사용자가 쿠키로 로그인을 요청하게 되면, 서버가 쿠키의 세션 ID로 메모리를 조회해 로그인 처리함
  • 단점
    • 서버에 세션저장소를 사용하기 때문에 요청이 많이 지면 서버 과부하가 됨.
• JWT(Json Web Token) : Json format으로 사용자에 대한 정보를 저장할 수 있는 웹 Token.
  • 장점
    • 토큰을 이용해서 토큰에 필요한 정보를 저장해 상호작용하기 때문에 별도의 인증이 필요하지 않음.
  • 단점
    • JWT는 Payload를 탈취해 decode 하면 데이터를 볼 수 있기 때문에 보안문제가 존재
    • 토큰 임시 삭제 불가. 토큰 만료시간을 반드시 기입해야 함.
    • 정보가 많아질수록 토큰의 길이가 늘어나 네트워크 과부하가 됨.

02. 세션/쿠키와 토큰 비교

세션

1. 사용자 로그인 요청
2. 서버에서 계정 정보를 읽어 사용자를 확인 ➜ 사용자 고유 ID를 부여 ➜ 세션 저장소에 저장 ➜ 이와 연결된 세션 ID를 발급
3. 사용자는 서버에서 해당 세션 ID를 받음 ➜ 쿠키에 저장 ➜ 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냄
4. 서버는 쿠키를 받아 세션 저장소에서 대조 ➜ 대응되는 정보를 가져옴
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줌

문제점

클라이언트에 모든 인증정보가 담겨 있다면 HTTP request가 해커의 의해 탈취당했을 경우 사용자 정보는 바로...👋🏻

해결방법

1. HTTPS사용, 서버와 클라이언트 간의 주고받는 정보를 암호화하여 요청을 탈취해도 정보를 읽을 수 없다.
2. 세션에 유효시간을 지정한다. (일정 시간이 지나면 해당 클라이언트와 서버와의 세션을 끊는다.)

토큰 기반 (JWT)

1. 사용자 로그인 요청
2. 서버에서 계정 정보를 읽어 사용자를 확인 ➜ 사용자 고유 ID값을 부여 ➜ 기타 정보와 함께 Payload에 넣음
3. JWT의 유효기간 설정
4. 암호화할 SECRET KEY를 이용해 Access Token을 발급
5. 사용자는 Access Token을 받아 저장 ➜ 인증이 필요한 요청마다 토큰을 헤더에 실어 보냄
6. 서버에서는 해당 토큰의 Verify Signature(전사서명)를 SECRET KEY로 디코딩 후 ➜  조작여부, 유효기간을 확인
7. 검증이 완료되면, Payload를 디코딩함 ➜ 사용자의 ID에 맞는 데이터를 가져옴

장점

1. 세션/쿠키는 별도의 저장소 관리가 필요하지만, JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다. 서버를 확장하거나 유지/보수하는데 유리!
2. 확장성이 뛰어남. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능.
   • 예를 들어 Facebook 로그인, Goggle 로그인 등은 모두 토큰을 기반으로 인증한다. 

문제점

1. 토큰 임시 삭제 불가. 토큰 만료시간을 반드시 기입해야 함.
   • 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지우면 되지만, JWT는 한번 발급되면 유효기간이 완료될 때까지 계속 사용이 가능하다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 정보를 해킹할 수 있음.
2. Payload의 정보가 제한적이다. Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.
3. 정보가 많아질수록 토큰의 길이가 늘어나 네트워크 과부하가 됨.

해결방법

1. 기존의 Access Token의 유효기간을 짧게 하고  ➜ Refresh Token이라는 새로운 토큰을 발급!
   • 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있다.

---

참고 문헌 REFERENCE

서버 인증 방식(세션/쿠키, 토큰)