JWT 기반 인증/인가 구현 시 UserDetailsService을 참고하지 않아도 되나요? 토큰으로만 해도 괜찮은지?

Question

우선 현재 서비스의 요구사항은 다음과 같습니다.ROLE을 통해 일반회원/유료회원을 구분하고 있습니다.회원가입 시 기본정보만 입력받아 회원가입을 수행하고, 이후에는 프로필 인증을 통해서 서비스내에 주요 기능을 이용할 수 있습니다. => status를 PENDING -> ACTIVE로 변환되어야 함즉, 회원가입 후에 프로필인증을 안 하면 PENDING 상태로 게시물 조회나 이런건 가능하지만, 작성이나 이런건 안됩니다.위 요구사항을 기반으로 처음 JWT Filter 구현할 때,subject에 memberId, 그리고 claims에 role 정보만 관리했습니다.그리고 Filter에서 오버라이딩해서 DB에 다녀오도록 구현한 UserDetailsService를 호출해서 DB에 저장된 유효한 사용자인지 판단했습니다.그럼 이때 해당 조회시점의 사용자의 status라든지 이런 정보를 토대로 Authentication를 SecurityContext에 저장하고 있었어요.이렇게 적재된 status 정보를 기반으로 프로필 인증된 회원인지에 따라서 로직을 수행하도록 했습니다.그런데 DB hit을 줄이는 게 좋다고하면서어차피 HTTPS로 통신하고, JWT의 시크릿 키값을 안전하게 만들어놨으면 claim 정보를 신뢰해도 된다고 하더라고요.그래서 애초에 claims에 role뿐만 아니라 nickname, status와 같은 정보도 저장해놓고유효한 jwt일 경우 claims에서 추출한 정보를 기반으로 Authentication을 만들어서 SecurityContext에 저장하는 방식도 있더군요.그런데 제가 생각하기에는 이 방식이 보안적으로 매우 안전하다고 하더라도 단점이 있다고 보거든요Access Token의 유효시간 내에 프로필 인증을 완료할 경우, 기존 Access Token을 재사용할 경우 status가 여전히 PENDING 상태임=> 따라서 프로필 인증을 완료할 때 response로 Access Token을 새로 발급해줘야 함..=> 결국 클라이언트는 Access Token을 다시 갱신해서 관리해야 함=> 만약 그렇지 않다면 사용자는 재인증(재로그인)을 해야 함..만약 멀티 로그인 환경(모바일의 경우 여러 기기)일 경우 다른 환경에서 관리하고 있는 Access Token에 대해서는 여전히 PENDING 상태임=> 물론 Access Token의 유효시간을 5분 내로 짧게 설정하겠지만,그 시간 안에 다른 기기로 이용한다고 할 경우 정합성이 맞지 않게 됨...=> 이거 하나 해결하자고 이벤트 처리로 동기화 시키는 건 말도 안되는 비효율성이라 생각함...위 2번 문제 때문에 DB에 다녀오는 게 맞지 않나 싶다가도..아래 장점 때문에 괜찮나..? 싶기도 하고....정말 DB조회가 필요한 경우 아니라면인증정보를 확인해야 하는 요청에 대해서 기본적으로 DB조회를 수행하지 않아도 되니까 성능상 되게 이점이 될 거 같습니다.뭐 사실 프로필 인증의 경우 다시 미인증으로 돌아갈 일도 없을 뿐더러, 계정당 일회성으로 발생되는 이슈이기 때문에프로필 인증 후 Access Token을 재발급해주는 건 크게 상관은 없을 거 같기도 하고요.물론 2번 문제에 대해서는 명확히 해결하기 위해서는 매우 비효율적인 건 여전할 거 같습니다...2번 하나 때문에 Access Token을 되게 짧게 잡으면 Refresh Token을 통한 재발급이 더 빈번하게 일어나니..결국 JWT 클레임 정보로만 Authentication을 관리한다고 하면관리되고 있는 정보가 변경될 경우 현재 유효한 Refresh Token 말고는 나머지는 다 폐기처리해서 재인증(재로그인)을 수행하도록 해야 할 거 같긴 합니다.이러한 트레이드오프 상황에서 중~대규모 트래픽 서비스를 원활하게 유지하려고 할 경우어떻게 해결하는 것이 좋을지 궁금합니다.일단 개인적인 생각으로는 무조건 인증/인가에 대해서는 DB hit이 발생하더라도 확실하게 해당 시점에 DB에 저장된 유효한 정보를 가져다가 쓰는 게 맞는 것 같긴 합니다만여러 사람들의 의견이 궁금합니다.

왕감쟈 · Answer

redis를 사용하시죠

더후디 · Answer

1 -> 유저 클라이언트 측에서 자동으로 토큰 재발급을 요청하도록 처리하면 되긴 합니다. refresh token 기반으로 하든, api 를 하나 새로 따서 단순 재발급 요청이든 간에요. 어쩌피 PENDING 상태더라도 토큰 자체는 유효하니 새로 발급해서 건내주면 되니까요.2-> 다 클라이언트 환경에서의 클라이언트 간 상태 정합성 문제의 경우, 크게 신경 쓸 필요가 있을 지 모르겠네요. 어쩌피 해당 이벤트는 유저가 해당 서비스를 이용하면서 맨 처음에만 일어날 사건이고, 이런 "한번의 번거로움" 정도는 크게 신경쓰지 않는다고 봅니다.유저도 대부분은 직관적으로, 아 핸드폰에서 인증이 완료되었으니, 컴퓨터에서 새로고침 등을 해야겠구나~ 정도는 알테니, 그냥 토큰 재발급 하는 "상태 업데이트" 버튼 같은거 하나 눈에 잘 보이는 곳에 넣어주면 되지 않을까요

apidevelop222 · Answer

프로필 인증을 완료할때 토큰을 만료시켜서 로그아웃으로 유도하여 토큰갱신하게 하세요프로필 인증을 완료할때 토큰을 재발급시키세요

adkb · Answer

정말 DB조회가 필요한 경우 아니라면인증정보를 확인해야 하는 요청에 대해서 기본적으로 DB조회를 수행하지 않아도 되니까 성능상 되게 이점이 될 거 같습니다.뭐 사실 프로필 인증의 경우 다시 미인증으로 돌아갈 일도 없을 뿐더러, 계정당 일회성으로 발생되는 이슈이기 때문에프로필 인증 후 Access Token을 재발급해주는 건 크게 상관은 없을 거 같기도 하고요.물론 2번 문제에 대해서는 명확히 해결하기 위해서는 매우 비효율적인 건 여전할 거 같습니다...2번 하나 때문에 Access Token을 되게 짧게 잡으면 Refresh Token을 통한 재발급이 더 빈번하게 일어나니..결국 JWT 클레임 정보로만 Authentication을 관리한다고 하면관리되고 있는 정보가 변경될 경우 현재 유효한 Refresh Token 말고는 나머지는 다 폐기처리해서 재인증(재로그인)을 수행하도록 해야 할 거 같긴 합니다.<--이미 포인트를 잡으신것같은데 클라이언트 측에서 무언가를 하던간에백엔드에서 한번 더 검증해야합니다.클라이언트 개발자가 플로우상 오류를 내면 어떻게 하실거에요?그리고 DB HIT을 왜 두려워하시는지요?중간에 Role 이나 작성하신 status를 변경하셨을때 즉시 반영을 어떻게 하시려고 하시는지요또한, 사용자가 탈퇴하였을 때 해당 stateless token(jwt,bearer token)을 어떻게 무효화해야할지 생각해보면결국 영속성 장치에 HIT해야한다는 것을 깨달을겁니다

JWT 기반 인증/인가 구현 시 UserDetailsService을 참고하지 않아도 되나요? 토큰으로만 해도 괜찮은지?

4개의 답변

Q&A 목록