JWT의 장점

• stateless 하기 때문에 기존의 session 방식에 비해 리소스 소모가 적다.
• 빠르게 사용자 인증(Authentication) 정보를 생성할 수 있다.

<aside> 💡 Authentication - 인증, 입증, 인가 Authorization - 권한 부여

</aside>

JWT의 단점

JWT 생성 시 문제

• "alg": "none" 공격

  jwt 생성 시 HEADER 영역의 alg 속성에 none 이라고 작성하면 간혹 어떤 서버들은 입장시켜 주는 경우가 발생하기 때문에 보안에 취약하다. → 현재 최신 버전의 jwt 라이브러리 사용 시 해결

• jwt는 디코딩이 매우 쉽다.

  jwt는 디코딩이 매우 쉽기 때문에 jwt 생성 시 Payload에 민감한 정보들은 작성하지 않는 것이 좋다. 가능한 최소한의 정보들만 작성하는 것이 좋다.

• 시크릿키 문제

  jwt 생성 시 시크릿키를 포함하는데 시크릿 키를 너무 쉽게, 단순하게 작성하면 보안에 취약할 수 있다. 키를 복잡하고 길게 작성하거나, 생성용키/검증용키 2개를 사용하여 키를 생성하는 방법도 존재한다. (private key + public key)

JWT 탈취로 인한 문제

예를 들어 헬스장 입장권을 잃어 버리면 그 책임은 잃어버린 회원에게 있지만 솔루션으로 헬스장에서는 그 입장권 사용을 중지시켜 줄 수는 있어야 한다. 그래서 jwt 탈취 시 솔루션이 존재한다.

(session의 경우 기존 인증 토큰을 탈취 당하면 다시 새로운 인증 토큰을 재발급 해주면 되는데, jwt의 경우 stateless하기 때문에 재발급을 할 수가 없다. stateless 하기 때문에 서버에 회원에 대한 인증 토큰 데이터가 없다.)

• 솔루션1: 훔치기 어렵게 만든다.

  *HttpOnly cookie를 사용하여 jwt 토큰을 훔치기 어렵게 만든다.*

• 솔루션2: jwt 블랙리스트

  session과 유사한 방법으로, 접근 불가능한 jwt토큰 목록들을 서버에 저장해 두고, 인증할 때 마다 조회하는 방식인데 jwt를 사용하는 장점이 사라진다. → session 방식이랑 별차이 없게됨

• 솔루션3: jwt 유효기간을 짧게 설정한다.

  jwt의 유효기간을 짧게 5분으로 설정하여 5분뒤 해당 jwt 토큰은 쓰레기가 되어버린다.

  그런데, 유효기간이 지나면 기존의 jwt 토큰 데이터를 사라지지만 새로 토큰 데이터를 만들기 위해서는 refresh token 이라는 것을 따로 운영해야 한다. 그래야만 유효기간마다 새로 jwt 토큰 발급이 가능하다.