JWT 토큰이란,
Json Web Token 으로, 인증과 관련한 정보를 JSON 객체에 저장한후 암호화 시킨 토큰을 의미합니다.
JWT 구조
모든 부분의 구조는 JSON 형태를 갖는다
각 부분은 . 연산자를 이용해서 구분된다
- Header
- typ : 토큰의 타입을 지정
- alg : Signature 부분을 해싱하기 위한 알고리즘 정의
- Payload
- 토큰에서 사용할 정보의 조각들 : 클레임이라고 한다
- Signature
- 토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드
JWT 과정
로그인 전
- 사용자가 로그인을 요청합니다.
- 서버는 암호화 JWT를 발급합니다.
- JWT를 헤더에 담아서 클라이언트에게 보냅니다.
로그인 후
- 서버로 부터 받은 JWT를 로컬에 저장합니다.
- API 요청할때마다 헤더에 JWT를 담아서 보냅니다.
- 서버는 헤더에 JWT를 확인하여 신뢰할 수 있다고 확인하고 API의 응답을 제공합니다.
왜 JWT를 사용해야할까
HTTP의 특성
- Connectionless : 한번 연결이되어 통신을 완료한 후에는 연결이 끊어진다.
- Stateless : 이전의 상태를 기억하지 못한다.
즉, 한번 통신이 일어난 후에는 연결이 끊기고 이전의 상태를 기억하지 못하는 것이다. 그렇다면 현재 API를 요청하는 클라이언트가 신뢰할 수 있는 클라이언트인지를 확인할 수가 없다.
이러한 문제를 해결하기위해 JWT로 신뢰성을 챙겨 재인증 하지 않도록 한다.
만약, Session을 이용해서 사용자의 정보를 저장해서 로그인과 같은 기능을 구현하려고한다면 서버는 모든 사용자에 대한 정보를 Session 영역에 저장해야 되고 너무나 많은 정보로 비효율적인 방법이 되어버립니다.
장단점
- 장점
- 로컬에 저장하기때문에 서버의 용량에 영향을 주지않는다.
- 안전하다
- http 헤더나 파라미터를 통해 간단하게 전송되기에 네트워크 부하가 적다
- 단점
- 토큰 크기가 크면 트래픽에 영향을 미친다.
- 토큰 만료 기간 변경이 불가하다, 토큰 만료처리를 구현해야한다.
RefreshToken, AccessToken
JWT토큰을 사용하면 만료기간을 설정해줄 수 있습니다. 하지만 만약 JWT토큰을 사용해서 통신을 하고 있다가 비정상적인 경로로 토큰을 빼앗기는 경우를 생각해봅시다. 만료기간을 너무 길게 설정한다면 이 위험성이 높아질것입니다. 반대로, 너무 만료기간을 짧게 설정한다면 너무 자주 JWT토큰을 생성해야되고 이는 비효율적일 것입니다.
따라서! JWT 토큰을 AccessToken과 RefreshToken으로 나누어서 사용합니다.
AccessToken
JWT의 본체와도 같다.
사용자에 대한 중요한 정보를 갖고있고 서버가 관리합니다.
RefreshToken
JWT에 들어있는 사용자의 정보중 간단한 정보들만 저장한 경량화된 토큰입니다.
클라이언트와 서버가 통신할때 사용하는 토큰입니다.
클라이언트에게 저장돼서 사용됩니다.
적용방식
- 클라이언트는 서버에게 로그인을 요청합니다.
- 서버는 클라이언트에게 RefreshToken을 제공합니다.
- 클라이언트는 RefreshToken을 갖고 서버에게 API 요청을 합니다.
- 서버는 클라이언트가 갖고온 RefreshToken을 정보를 확인하고 진행합니다.
RefreshToken이 탈취당할 위험은??
RefreshToken은 사용자의 중요정보가 아닌 서버가 확인하고자 하는 정보만 들고있는 경량화된 토큰으로 JWT토큰의 모든 정보를 탈취당하는 것보다 안전합니다.
또한 RefreshToken의 만료기간을 짧게 설정하여서 탈취당할 위험성을 낮춥ㄴ다.만료기간을 짧게 설정하면 괜찮을까??
토큰이 만료되면 다시 재생성하는 과정이 번거롭고 비효율적이라고 하였습니다.
하지만, RefreshToken은 만료기간이 다되었다면 서버는 RefreshToken의 정보와 서버가 갖고있는 AccessToken의 정보를 비교해서 올바른 정보인지를 확인합니다. 후에 올바른 토큰으로 확인되면 만료기간을 연장시켜주기 때문에 비효율적인 문제를 해결할 수 있습니다.
자세한 과정
