JWT 원리 및 장/단점

JWT 원리

Header, Payload, Signature가 JWT의 구성요소이다. 이들이 JSON형태로 담겨있어서 Json Web Token이다.
이들을 부호화하고 암호화시켜 만들어낸 것이 오른쪽 형태이다.

• Header에는 어떤 알고리즘으로 암호화 할 것인지, 토큰은 어떤 타입을 쓸 것인지와 같은 토큰 관련 정보가 담긴다.
• Payload에는 사용자 인증 관련 정보가 담긴다. 수정이 가능하여 더 많은 정보를 추가해둘 수도 있다. 그러나 이 곳은 노출과 수정이 가능한 지점이기에 인증이 필요한 최소한의 정보만 담아야한다! 인증에 필요한 최소한의 정보란 아이디, 비밀번호, 개인정보 등이 아니라 이 토큰을 가졌을 때 권한의 범위, 토큰의 발급일과 만료일자 등을 의미한다.
• Signature 부분이 가장 중요한 역할을 한다. 이 곳에서는 부호화시킨 Header와 Payload를 가지고 발급해준 서버가 지정한 secret key로 암호화 시킨다. 이렇게 하면 토큰을 변조하기가 어려워진다.
  구체적인 사례를 들어보면 이렇다.

토큰 발급된 이후에 누군가 Payload 정보를 수정한다.
Payload는 조작된 정보가 들어가 있지만 Signature에는 변경되기 전 Payload 내용을 기반으로 암호화된 결과가 저장되어 있다. 조작 후 Payload를 암호화한 결과와는 다른 값이 나온다! 이러한 방식으로 비교하면 서버는 토큰 조작 여부를 쉽게 알 수 있다.

JWT로그인 장/단점

장점

• 별도의 저장소 불필요, 서버 자원 절약
• 불필요한 인증 과정 감소, 트래픽 위험 저조

인증 관련 정보를 DB에 저장한다면 이용자수가 늘어나는만큼 저장 공간이 더 많이 필요해진다. 또한 인증 시마다 DB를 사용하므로 인증이 몰리면 서버가 과부하될 위험이 있다.

반면 JWT는 별도 저장소가 필요치 않아 서버자원을 절약할 수 있고 인증 과정에서 다른 곳을 거칠 필요없어 효율적이다. 인증 정보를 가진 특정 서버에만 트래픽이 몰릴 일도 없다. 서버 부하를 줄이기 좋은 방식이다.

단점

• 외부 공격자가 접근하기 쉬운 위치, 노출 가능한 정보
• 노출 가능성으로 인해 저장할 수 있는 정보가 제한적이다.
• 암호화가 풀릴 가능성을 배제할 수 없다.
  -> 암호화가 풀리더라도 토큰을 사용할 수 없도록 만료기간을 짧게 설정한다. 짧게는 5, 6분만 유지되는 경우도 존재하며 길어도 1시간을 넘기지 않는다고 한다.

refresh token을 사용하는 이유

• 리프레시 토큰은 jwt 보안상의 단점을 보완하기 위해 구현한다.
• 리소스에 접근할수있는 토큰을 액세스 토큰이라고 하는데, 클라이언트 상에 노출되어있으므로 비교적 탈취가 쉽다. 그래서 액세스 토큰의 유효기간을 짧게하여 공격받을 면적을 줄이는 것으로 보완성을 높인다. 이런 단점을 보완하고자 고안된 것이 리프레시 토큰이다.
  1. 엑세스 토큰과 리프레시 토큰의 발급
  2. 액세스 토큰에 짧은 만료주기 설정
  3. 리프레시 토큰으로 액세스 토큰을 재발급
  4. 기존의 액세스 토큰 폐기

출처:https://velog.io/@mygomi/TIL-50-JWT%EC%97%90-%EB%8C%80%ED%95%B4-%EB%B0%9C%ED%91%9C%ED%95%B4%EB%B3%B4%EA%B2%A0%EC%8A%B5%EB%8B%88%EB%8B%A4