[JWT] JWT(Json Web Token)

2021. 10. 30. 15:51개발공부/Spring

JWT(Json Web Token)

Authentication을 마치고 Authorization이 일어날 때, 기존의 방식인 session과 달리 JWT는 scalability와 multiple device 사용이 가능합니다.

JWT는 DB를 거치지 않고 Base64로 인코딩된 토큰을 헤더에 전달해 서버에서 validate 한다음 Authorization을 주는 토큰방식입니다.

JWT는 .으로 구분된 세개의 부분이 존재합니다. 첫 부분은 header로 알고리즘 종류와 토큰 타입이 담깁니다. 두 번째 부분은 payload로 비즈니스 도메인에서 식별이 필요한 내용(ex. 사용자 이름, id 등)이 들어갑니다. 그리고 마지막 3번째는 앞선 두 부분에 담긴 정보를 공개되지 않은 secret key를 활용해 Encrypt한 해싱 데이터가 들어갑니다. 따라서 제가 토큰의 앞선 두 부분을 변경해도, secret key로 해싱했을 때 데이터가 일치하지 않으면 Authorization이 이루어지지 않습니다.

image

[출처: https://jwt.io/ ]

그렇다면 JWT가 각광받는 이유는 뭘까요? 우선 DB를 접근하지 않기 때문에 성능을 높일 수 있고, DB에 값을 저장하지 않기 때문에 Scalability(확장성)을 절약할 수 있습니다. 갈수록 사용자 트래픽이 많은 서비스들이 생기면서 Scalability의 중요성이 커지고 있습니다. 이에 JWT는 좋은 대안이 될 수 있지만, 외부 공격으로 특정 JWT를 막아야 될 때, 만료 시간이 되기 전까지 핸들하지 못하는 한계도 분명 존재합니다. 이럴 경우 access JWTrefresh 토큰를 혼용할 수 있습니다.

access JWT & refresh Token

access JWT의 장단점은 명확합니다. 장점은 앞서 언급했듯이 DB를 건드리지 않아도 된다는 점입니다. 하지만 단점은 보안 상 이유로 토큰을 revoke(만료) 시켜야할 때 방법이 없단 것입니다. 이 경우 보완가능한 것이 refresh Token을 사용하는 것입니다.

access JWT의 만료시간은 5~10분으로 짧게 잡고, 만료가 됐을 때 refresh Token을 서버에 전달해 JWT를 갱신받는 과정이 반복됩니다. 물론 refresh Token은 서버 DB에 저장이 되어야합니다. 서비스의 특성에 따라 memCached된 Redis DB에 Token을 저장할 수도 있지만 서버에 애플리케이션들이 많아지기 때문에 서비스의 특징을 고려해 DB를 사용하던 memCached DB를 사용하면 됩니다.


참고자료