JWT 중복로그인 방지

JWT를 이용해서 인증을 한다면 중복 로그인에 대한 문제를 반드시 겪게 되는 것 같습니다. 

 

로그인을 한 사용자가 다시 로그인을 한다면 이 로그인을 막아야할텐데 (구현은 stateful하게 하지만) stateless인 JWT 특성상 인증과 관련된 부분이 서버와 격리되어있어 서버에서 처리를 하지 못하는 상황이 발생합니다. 

 

이미 발급된 access token (이하 AT) 를 어떻게 제어할 수 없다는 문제가 발생하죠. 

 

JWT 중복로그인 방지

이를 해결하기위해 중간 단계를 거칠 수 밖에 없었습니다. 모든 코드를 다 보여드리기엔 양이 많아 개요만 포스팅하려고 합니다. 

 

먼저 일반적인 JWT는 이렇게 인증을 거칩니다. 

 

이건 JWT를 아시는 분들에겐 친숙한 흐름도일 것입니다. 

 

하지만 로그인을 한 사용자가 또 로그인을 하는 상황은 어떻게 대처해야할까요? 

 

세션을 사용한다면 기존 세션을 없애버리고 새로운 세션을 생성하면 됩니다. 하지만 이미 발급된 AT는 어떻게 할 방법이 없기 때문에 저는 Redis에서 AT를 한번 더 검증하는 과정을 거쳤습니다. 

 

 

그렇게 하기 위해서 결국 로그인 과정에서 클라이언트 (브라우저) 별 고유값을 서버에 전달할 수 밖에 없었고 서버는 이 고유값을 이용해 Redis에서 토큰을 검증하고 접근을 막을 수 있었습니다. 

 

장점

장점은 뭐니뭐니해도 중복로그인을 방지할 수 있다는 것이죠. ChatGPT는 중복로그인을 막지 않았더군요. 하지만 인프런같은 사이트는 어떨까요? 아이디의 공유를 방지하기 위해서라도 중복로그인을 방지해야합니다. 

 

이런 사이트에선 중복로그인을 방지하는 것이 큰 장점이 될 수 있습니다. 

 

단점

Redis에 토큰을 고유값으로 지속적으로 검증해야한다는 단점이 있습니다. 물론 Redis가 캐시 데이터베이스로 이용되기 때문에 일반적으로 RDB에 접근하는 것보다 리소스가 적게 들어가지만 네트워크 I/O나 CPU자원이 소모되는 것은 사실입니다. 

 

 

결론

중복로그인을 방지하지 않아도 된다면 그냥 냅두는 것도 좋은 방법이라고 생각합니다. 우리 서비스에 잘 맞는 인증 정책을 가져가면서 어떤 것이 좋을지 고민해보고 적용하는 것이 좋을 것 같네요. 

 

저희 회사에선 중복 로그인을 방지해야 하는 입장이었어서 JWT인데 중복로그인을 방지하기가 꽤나 까다롭더군요. 

 

마치며

JWT 중복 로그인 방지는 이론적으로 크게 어려운 내용은 없지만 코드 내용은 많아 포스팅이 짧아지게 된 것이 조금 아쉽긴 하네요. 짧지만 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~