Access Token
사용자가 로그인을 할 때 클라이언트에게 AccessToken을 발급한다.
서버는 AccessToken을 데이터베이스나 파일등에 저장 할 필요 없이 메모리상에서 미리 정의 된 비밀키를 이용해 비교하는 것 만으로 인증을 처리하기 때문에 추가적인 I/O 작업이 필요가 없다.
하지만 몇가지 단점이 있다.
- 토큰 만료 기간이 짧아, 자주 로그인을 다시 해야한다.
- 한번 생성된 토큰은 제거되지 않는다.
그럼 어떻게 로그아웃을 해?!
블랙리스트를 사용하여 여전히 유효하지만 인증에 사용할 수 없는 JWT를 저장할 수 있다.
고유 식별자 jti를 JWT에 추가해야한다. 블랙리스트 에는 jti 및 exp가 포함된다.
현재 시간> exp가되면 항목을 버릴 수 있습니다.
Sliding Sessions
보안성과 편의성 모두를 잡을 수는 없을까를 고민하다가 나온 것이 Sliding Sessions전략이다.
이 전략은 세션을 지속적으로 이용하는 유저에게 자동으로 만료 기한을 늘려주는 방법이다.
구현 방법은 다양하지만 주로 유효한 AccessToken을 가진 클라이언트의 요청에 대해 서버가 새로운 AccessToken을 발급해주는 방법을 사용한다.
매 요청마다 새로운 토큰을 내려주는 것도 가능하지만, 글을 작성하다가 인증이 만료되는 참담한 경우를 막기 위해 글 작성을 시작할 때 발급해준다거나, 쇼핑몰에서 장바구니에 아이템을 담는 경우에 발급해주는 등의 전략을 사용하는 것도 괜찮은 방법이다.
또 클라이언트가 토큰의 iat(토큰 발급 시간)속성을 참조해서 갱신 요청을 하는 방법도 있다.
이 방법을 활용하면 AccessToken만을 이용해 인증을 처리할 때 있었던 단점을 보완해 줄 수 있다.
Refresh Token
Access Token만 사용하게되면 자주 로그인을 해야하는 단점이 있다고 했다.
이러한 단점을 해결하기 위해 Access Token 과 Refresh Token 를 같이 사용하는 방법이 있다.
사용자가 로그인을 할 때에 AccessToken과 함께 그에 비해 긴 만료 시간을 갖는 RefreshToken을 클라이언트에 함께 발급한다.(주로 AccessToken은 30분 내외, RefreshToken은 2주에서 한달 정도의 만료 기간을 부여함)
클라이언트는 AccessToken이 만료되었다는 오류를 받으면 따로 저장해두었던 RefreshToken을 이용하여 AccessToken의 재발급을 요청한다.
서버는 유효한 RefreshToken으로 요청이 들어오면 새로운 AccessToken을 발급하고, 만료된 RefreshToken으로 요청이 들어오면 오류를 반환해, 사용자에게 로그인을 요구한다.
AccessToken은 서버에 따로 저장해 둘 필요가 없지만, RefreshToken의 경우 서버의 stroage에 따로 저장해서 이후 검증에 활용해야 한다.
그러므로 RefreshToken을 이용한다는 것은 추가적인 I/O 작업이 필요하다는 의미이며, 이는 I/O 작업이 필요없는 빠른 인증 처리를 장점으로 내세우는 JWT의 스팩에 포함되지 않는 부가적인 기술이다.
RefreshToken은 탈취 되어서는 곤란하므로 클라이언트는 보안이 유지되는 공간에 이를 저장해두어야 한다.
RefreshToken은 서버에서 따로 저장을 하고 있기 때문에 강제로 토큰을 만료시키는 것이 가능하다.
