JWT 토큰을 사용할때

Question

안녕하세요. JWT 토큰에 관해 질문드립니다.친구들과 간단한 서비스를 만들어보고 있는데,로그인 이후 인증 방식을 JWT를 사용해 구현해보려 합니다.물론 간단한 서비스다 보니 세션 + Redis 방식을 써도 무방하지만,이번에는 JWT로 stateless 인증 방식을 경험해보고 싶어서 선택했습니다.저희 서비스는 "알바천국"처럼회원 종류(개인회원/기업회원)에 따라 프론트에서 보여주는 화면이 다릅니다.이 상황에서 저와 친구의 의견이 갈렸습니다:저는 토큰 생성 시 payload에userId, 회원 종류(개인/기업) 정보를 함께 담고 싶습니다.민감한 정보는 아니기 때문에 문제가 없고,프론트에서는 이 정보를 디코딩해서 요청 없이 바로 화면을 분기할 수 있어 빠를 것 같다고 생각합니다.또한, 요청마다 DB에 접속하지 않아도 되어 서버 부하를 줄일 수 있을 거라 생각합니다.친구는 payload에는 userId만 넣고,서버에서 userId를 기반으로 SecurityContextHolder에 사용자 인증정보를 저장한 다음,컨트롤러에서 @AuthenticationPrincipal을 통해 필요한 정보를 가져와야 한다고 주장합니다.이렇게 하면 보안상 더 안전하다고 말합니다.제가 궁금한 점은 다음과 같습니다:친구의 방법(SecurityContextHolder 방식)을 쓰면, 요청이 올 때마다 userId를 기준으로 매번 DB에 접속해야 하는 것 아닌가요?(회원 종류를 알아내기 위해서요)단순히 프론트에서 화면 분기용으로 필요한 정보라면, 민감하지 않은 데이터는 토큰 payload에 함께 넣는 것이 효율적이지 않나요?SecurityContextHolder 방식을 사용하면, 추후에 트래픽이 많아졌을 때서버 메모리 사용DB 커넥션 수 증가 이슈가 생길 수 있을 것 같은데, 이런 단점은 없는지 궁금합니다.추가로 제 생각은 이렇습니다:글쓰기, 회원정보 수정, 결제 등 중요한 기능들은 SecurityContextHolder를 통해 인증정보를 서버에서 검증하고 처리하는 것이 맞다고 생각합니다.하지만 단순히 화면을 다르게 띄우는 것 정도는 payload에 안전하게 담아서, 추가 DB 조회 없이 빠르게 처리하는 편이 더 좋지 않을까 생각하고 있습니다.결론적으로, 이 상황에서는 어떤 방식이 더 좋은 선택인지, 실무에서는 보통 어떻게 설계하는지 조언을 듣고 싶습니다.진짜 제 방식이 보안상 큰 문제를 불러올 수 있나요?

하루의_spring · Answer

SecurityContextHolder 는 DB 갔다 오는게 아닙니다 로컬쓰레드에 인증정보가 저장되며 본인만 접근할 수 있는 고유 스레드입니다다만 UserId 를 가지고 부가 정보 (개인/기업) 이런 정보를 가져올떄는 UserId 를 가지고 DB 를 갔다오는것은 동일하지만 저라면그 정보까지도 SecurityContextHolder 에 담아 둘꺼 같습니다

오리구이 · Answer

친구분의 로직이 맞아 보입니다. 그렇게 하세요. 매번 db를 조회해야 정상입니다.

Kyeongrok Kim · Answer

token발급 해줄 때 Role을 넣어줄거냐 말거냐인데요 저는 넣는게 맞지 않나 싶어요. 안그러면 token검증 한 후 payload에 있는 userID로 db에 select를 날려야 하는데 Role정보를 db에 저장했다면 api 1개 요청 할 때마다 DB를 계속 갔다와야 하는데 RDB라면 이게 db부하를 주거든요.Role이 User였는데 Admin으로 payload를 변조 시켰으면 token을 풀 때 이미 변조됐다고 해서 액세스 거부를 하는게 맞지 않나요?MSA적으로도 Gateway에서 인증 했으면 그 뒤쪽에서는 bypass할려고 JWT쓰는게 아닌가 싶은데 제가 보안쪽은 배움이 짧아서 여기까지입니다.

휘뚜루마뚜루루 · Answer

저 같은 경우에는 Role은 자주 바뀌지 않기 때문에 JWT의 클레임에 포함해서 사용하고 있습니다.실제 운영 환경에서는 JWT를 사용하더라도 완전한 Stateless 구조를 유지하기는 어려운데.그래서 Role이 변경된 경우에는 해당 사용자의 토큰을 Redis 블랙리스트에 등록하고 다시 로그인을 유도해 변경된 Role이 반영되도록 처리했어요.다만 JWT에 너무 많은 정보를 담으면 네트워크 비용이 증가하고, 반대로 너무 적으면 매번 DB를 조회하게 되어 부하가 증가하며 이 경우 JWT의 장점이 희석될 수 있습니다.결국 JWT에 어떤 데이터를 담을지 적절한 밸런스를 조절하는 것이 백엔드 개발자의 중요한 역할이라고 생각드네요.

axc · Answer

저도 사이드 프로젝트로 jwt +redis + auth2.0을 사용해 구현 중인데요, 비슷한 고민을 정말 많이 하는 것 같습니다.지금도 하고 있구요. 일단 저도 위에 분들과 같이 user Role값은 클레임에 담아서 사용하고 잇습니다.

바냐파노 · Answer

저는 찌를 때마다 DB조회는 낭비 혹은 불가능일 수도 있다고 보는데요MSA 구조에서 토큰을 발급하는 주체와 사용하는 쪽이 다를 수 있기 때문입니다. 발급하는 쪽이 회원DB를 가지고 있고, 사용하는 쪽에서는 가지고 있지 않다고 했을 때 DB를 구조적으로 찌를 수가 없겠죠.

똑똑한청년345 · Answer

윗 분들이 이미 많은 설명을 해주셨지만 저도 Role은 payload에 담아도 괜찮다고 생각합니다.보안적으로 중요한 api 가 있다면 annotation 활용해서 해당 api 호출 할 때, interceptor를 사용해 DB 조회를 통해 검사하거나 혹은 특정 url 검사를 해도 좋을 것 같아요

wharup · Answer

회원 종류에 따라 화면을 분기하는 건 서버 단 보안이랑 큰 상관이 없습니다.JWT에 있으면 그걸 써도 되고, 없으면 로그인하고 사용자 정보를 API로 조회하면 됩니다.그리고 JWT에 민감 정보를 넣어도 되냐는 여러 관점이 있을 수 있는데요사용자의 ROLE 처럼 민감한 정보를 JWT에 넣는 경우에는 JWT를 암호화하는 JWE를 사용합니다. 이 경우는 화면에서도 내용을 볼 수 없습니다.그리고, 암호화했더라도 값이 바깥으로 나가는 걸 싫어하는 경우도 많습니다. 그런 경우 JSessionid처럼 해시값만 반환하고 DB/세션에서 정보를 조회합니다.그리고 JWT건 세션이건 SecurityContextHolder는 다 사용합니다.SecurityContextHolder는 메모리에 있는거라 조회하는 성능을 걱정할 필요는 없고요SecurityContextHolder를 생성할 때 데이터의 출처가 JWT냐 세션이냐 DB냐에 따라 성능 이슈가 있을 수 있는데 규모가 있으면 보통 세션 저장소를 따로 둬서 해결합니다.

WLM · Answer

권한을 나만 수정할 수 있다는 전제하에유저 식별자와 클라이언트 식별자를 기록한 테이블정도만 Redis에 저장해두면(로컬 메모리안됨 central storage인데 메모리기반) 서버푸쉬 이벤트로 최적화 할 수 있을것 같은데요권한 수정하면 서버에서 푸쉬 이벤트로 특정 유저 식별자로 접속중인 모든 클라이언트(절대 대부분은 브라우저겠죠)에 쿠키지우라고 하면 될듯합니다푸쉬 이벤트는 SSE 이용하시면 될거같고 Redis 테이블에서 기록,정리하는건 적당히 기준 세우시면 될거같은데 저는 SSE 커넥션 연결,끊김으로 처리할거같긴합니다 (당연히 한번 연결해두면 안끊기게 keep-alive 랑 하트비트 잘 설정하셔야하고요 그럴일은 드물어보이지만 브라우저당 커넥션 수 부족해지면 http 2.0 사용도 고려해보시고요)근데 단순히 권한에 따른 페이지 분기이고 그 페이지에 권한에 따른 차등정보가 노출되는게 아니라면 전 솔직히 이런 구현도 필요 없다 생각이듭니다 ..민감한 정보가 노출되는 데이터들이라면 페이지를 따로 분기하고 그 페이지 접속시에는 무조건 DB찍고 Role 검사하도록 처리하면 403 에러내고 로그아웃시키든 토큰 재발급시키든 하면 될거같은데요?

JWT 토큰을 사용할때

9개의 답변

#springsecurity 목록