JWT 의 역사

✏️ JWT 토큰의 필요성

📍 모바일 앱이 없던시절

• 모바일 앱이 없던 시절엔 브라우저와 서버간의 통신이 대부분 이였다.
• 클라이언트는 ID, PW 로 인증을 완료하고 브라우저에 저장된 세션값을 쿠키에 담아서 요청하는 방법으로 로그인을 유지했다.
  • 이렇게 하면 간단한 CPU 연산만으로 로그인을 유지시킬 수 있었다.

📍 모바일 앱 등장

• 모바일 앱은 기본적으로 브라우저가 아니기 때문에 쿠키가 존재하지 않는다.
  • 즉, 브라우저 - 서버 간 통신처럼 쿠키를 통한 로그인 정보 전달을 할 수 없고, 로그인을 유지 할 수 없게 되었다.
• 해결책으로 초기에는 브라우저와 동일하게 ID, PW 로 인증을 완료한 후,
  앱 내부에 ID, PW 를 저장한 다음 추가로 요청할 때 마다 ID, PW 를 계속 포함시켜 로그인을 유지시켰다.
  - 클라이언트의 ID, PW 가 HTTP 매시지에 계속 포함되어야하는 찜찜한 문제가 발생했다.

📍 토큰으로 대체

• 이 찜찜한 문제를 해결하기 위해 토큰이라는 개념이 등장했다.
  • 토큰은 최초 인증을 완료한 후 난수를 생성해 기존 ID, PW 를 대신해 사용하는 역할을 맡았다.
• ID, PW 를 토큰이 대체했지만 문제점은 여전히 존재했다.
  • ID, PW 가 해킹 당할 위험이 있는것 처럼 토큰도 ID, PW 와 동일한 기능을 했기 때문에 해킹당하면 개인정보가 모두 털린다는 문제가 있었다.
  • 브라우저간 인증 방법처럼 CPU 연산을 통해 로그인을 유지하는 것이 아닌 DB 에 저장된 토큰을 SELECT 문으로 찾아야 되서 Query 를 계속해서 보내야 한다.
• 토큰의 도입으로 개선된 점은 몇가지 없었다.
  • 앱 내부에 ID, PW 를 저장하지 않아도 됨
  • 요청시 ID, PW 를 사용하지 않아도 됨
  • 해킹당할경우 토큰 갱신을 하기 편리함
    • 클라이언트가 새로운 PW 를 생각하지 않고 버튼 하나로 랜덤 난수를 생성하면 되기 때문

📍 JWT 등장

• 기존 토큰이 의미없는 난수를 사용했다면 JWT 는 클라이언트의 정보를 토큰에 담아 해시 (시크릿 키) 를 사용해 암호화를 한 토큰이다.
  • 클라이언트의 정보를 base64 를 통해 토큰으로 변환시킨다.
  • 변환시킨 토큰을 시크릿 키로 변조되었는지 한번 더 체크한다.
• 시크릿 키가 필요한 이유
  • 기존 토큰은 서버 DB 에서 클라이언트 정보를 조회하기 때문에 신뢰할 수 있었다.
  • base64 는 클라이언트 쪽에서 개인정보를 보내는 것이기 때문에 변조의 위험성이 있다.
  • 이 때 시크릿 키를 사용해 서버에서 생성한 토큰이 맞는지 검증해,
    토큰의 변조 유무를 확인할 수 있다.
• JWT 도입으로 신뢰할 수 있는 정보를 쿠키 없이 CPU 의 복호화 연산만으로 얻을 수 있게되었고,
  로그인을 유지시킬 수 있게 되었다.

✏️ JWT 의 한계

• JWT 는 클라이언트의 정보를 암호화 한 토큰으로 개인정보가 업데이트 되면 싱크가 맞지 않게된다.
  • 즉, 개인정보를 업데이트 할 때 마다 JWT 를 계속해서 새로 밠급시켜줘야 한다.
  • 이 과정이 번거롭기 때문에 JWT 토큰을 예전 토큰처럼 갱신없이 사용하는 경우도 존재한다고 한다.
    • DB 에서 클라이언트 정보를 조회하는 방식
• JWT 의 특성상 토큰을 강제로 만료, 갱신시킬 수 없다.
  • 즉 토큰을 한번 생성한뒤 탈취당하면 개인정보 연람을 막을 수 없다는 뜻이다.
  • 이 심각한 문제를 막기위해 refresh token , Redis , DB 조회 등 다양한 방법을 적용하고 있다.