Jwt BlackList?
사용자가 로그아웃을 요청했을 때, 클라이언트 측에서는 캐시에 저장된 jwt를 제거하지만 서버에서는 jwt를 무력화할 수단이 없다.
때문에 서버에서는 Jwt에 대한 블랙 리스트를 만들어 Jwt의 유효기간이 만료될 때 까지 Redis와 같은 DB에서 관리하는것을 말한다.
만약 사용자가 Jwt를 이용하여 인가를 요청했을 시, Black List의 조회를 통해 사용자가 로그아웃한 Jwt인지 아닌지를 판별하는 것이다.
의문점
여기서 한가지 의문점이 생긴다.
일단 세션의 경우에는 서버에서 세션의 값을 가지고 있으며 클라이언트가 인가를 요청했을시 Redis와 같은 DB에서 클라이언트의 세션과 서버가 가지고 있는 세션의 값이 일치하면 인가를 해준다.
Jwt의 Blak List는 어떤가? 사용자가 인가 요청을 하면 Redis와 같은 DB에서 클라이언트의 Jwt와 서버가 가지고 있는 Black List가 일치하지 않으면 인가를 해준다.
즉 둘다 Redis와 같은 DB에 종속되어 있으면서 stateless 하지 못하다는 의미이다.
그러면 그냥 일치여부만 확인하면 되는 세션을 사용하면 되지 왜 복호화 과정까지 거쳐야하고 Refresh Token까지 관리해야하는 Jwt를 사용하는 것인가?
해답
구글링을 통해 많은 사람들의 의견을 접해본 후 내가 내린 결론은 Case By Case 이고 관점의 차이인 것 같다.
일단 Jwt는 로그인에 초점을 맞춘 인증방식이지 로그아웃까지 고려한 인증방식은 아니라는 점이다.
적은 비용으로 서버를 확장시킬 수 있다는 점에서 MSA와 세션 스토리지를 확보할 자본이 부족한 스타트업에 적합한 기술인 것 같다.
세션의 경우는 stateful 하지만 서버에서 세션을 관리하기 때문에 세션을 탈취 당해도 서버측에서 대응할 수 있기 때문에, 보안이 많이 중요하면서 세션 스토리지에 추가 지출을 감수할 수 있는 대기업에 적합한 기술인 것 같다.
결론
내가 가진 지식으로 내린 결론은 Jwt의 이점을 최대화 하기 위해 로그아웃시 Black List를 구현하는 것이 아닌 클라이언트 캐시에서 Jwt를 제거, 서버에서는 해당 클라이언트의 refresh token을 제거 또 access Token의 유효기간을 적게 설정하는 것이다.
이러면 access Token와 refresh Token을 모두 탈취 당해도 로그아웃을 하면 새로운 access Token을 발급 받지 못하면서 access Token의 적은 유효기간으로 서버의 피해를 최소화 할 수 있다.
느낀 점
기술은 사람들이 많이 사용한다고 해서 모든 곳에 통용되는 것이 아닌 적재적소에 잘 사용해야 한다는 것을 깨달았다.
나는 Jwt에 대해 세션 다음으로 나온 기술이고 또 세션의 단점인 stateful을 해결했으니 세션보다는 Jwt를 무조건적으로 사용하는게 좋다고 생각하고 있었다.
하지만 이는 틀린 생각이였고 상황에 따라서는 Jwt보다 세션이 적합할 수 있다는 점을 깨닫게 되었다.
앞으로 나는 상황에 따라 어떤 기술이 적합한지에 대해 좀 더 고민하면서 그 상황에 맞추어 기술을 이용할 수 있게 여러가지 기술스택을 익히도록 노력해야겠다.
Refrence
