인프런 커뮤니티 질문&답변
작성한 질문수
중복로그인
작성
·
3.6K
0
안녕하세요, 좋은 강의 올려주셔서 정말 감사합니다.
강의 덕분에 프로젝트를 무사히 할 수 있게 되었습니다.
jwt 구현하면서 궁금한 점이 생겨 질문을 남기게 되었습니다.
jwt를 사용하면서 컴퓨터 a에서 로그인하고 나서 컴퓨터 b에서 로그인을 할 경우,
중복 로그인이 발생하는데 이전 강사님 강의에서는 세션을 사용하면 세션에서 방지할 수 있다고
배웠으나 jwt에서는 세션을 사용하지 않기 때문에 중복 로그인을 어떻게 막을 수 있는 지 궁금하여 질문을 남기게 되었습니다.
나름대로 찾아본 결과,
디비에 로그인을 시도에 대한 컬럼을 넣고 이전 로그인의 토큰을 무효화하고 이후에 들어온 로그인에 대한 토큰으로 인증을 처리
-> 이렇게 되면 액세스 토큰, 리프레시 토큰을 모두 디비에 넣던가, 아니면 액세스 토큰의 만료시간을 굉장히 작게 잡아서 사용해야 할 것 같은데 모두 디비에 넣고 사용하게 되면 jwt 방식에 대한 효율점이 적어지게 되는데 어떤 점이 좋은 지 궁금하여 남기게 되었습니다.
하드웨어의 ip 값을 디비에 저장해서 사용하는 것이 좋은 건가요?
읽어주셔서 감사합니다.
답변 1
0
네
사실 중복 로그인 문제는 세션 기반이든 JWT 기반이든 DB 의 도움을 받을 수 밖에 없는 한계가 존재합니다.
서버가 한 개일 경우에는 그나마 DB 가 아닌 메모리에 저장해도 되긴 하겠지만 서버 이중화일 경우 이 마저도 대안이 되지 못하고 더군다나 메모리 자체도 데이터 유실위험이 있기 때문에 결국 DB 에 세션 아이디든 토큰이든 저장해서 가장 최근 로그인한 사용자 외 기존 사용자의 토큰을 무효화 하거나 로그아웃 처리를 하는 방향으로 가는게 일반적인 방법이긴 합니다.
JWT 를 사용하는 장점중의 하나가 여러개의 서버라 할 지라도 JWT 자체에 계정 정보를 포함하고 있어서 DB IO 없이 자체 인증을 검증할 수 있다는 것이고 이것이 서버와의 상태를 유지하지 않아도 된다는 큰 장점인 것인데 중복 로그인처럼 뭔가 서버에 상태를 저장해 놓고 계속 유지해야 하는 상황이 발생하는 순간 JWT 의 장점이 크게 사라져 버린다는 것입니다.
가장 최근의 AccessToken 을 제외하고 기존의 Access Token 의 접근을 막든 가장 최근의 Refresh Token 이 아닌 기존의 Refresh Token 을 사용해서 AccessToken 를 재발급 받지 못하도록 해서 중복을 막든 둘 다 DB 에 토큰을 저장하는 것은 피하지 못합니다.
IP 도 아주 유니크 하지는 못합니다. 동일한 IP 에서 다른 브라우저로 여러 번 로그인이 가능하기 때문입니다. 물론 다른 IP 에서의 중복 접근을 막는 것이 더 중요하다면 고려해 볼 수 도 있습니다.
참고로 서버에 상태를 저장하지 않고 이 작업을 수행할 수 있는 유일한 방법이 토큰 수명 동안 새 토큰에 서명하는 기능을 비활성화하는 것이라는 내용을 어디에서 본적이 있는데 구체적으로 어떻게 구현해야 하는지 깊게 생각해 보지는 않았습니다. 혹 참고가 될 수 있을까 해서 적어 보았습니다.