jwt 관련 블로그 글 보고 있는데
다 UserDetailService imple한 C.ustomDetailService에 loadByUsername으로 userrepository.findById(Long userId) 으로
DB 조회 후 User 객체 가져오는데
이러면 세션이랑 다를 빠 없는거 아님...?
이거 우회하려고 하면 jwt claims에 유저 정보 넣어야할거같은데 그건 또 보안상 문제인거같은데
어떻게 해야하는 거임?
jwt 관련 블로그 글 보고 있는데
다 UserDetailService imple한 C.ustomDetailService에 loadByUsername으로 userrepository.findById(Long userId) 으로
DB 조회 후 User 객체 가져오는데
이러면 세션이랑 다를 빠 없는거 아님...?
이거 우회하려고 하면 jwt claims에 유저 정보 넣어야할거같은데 그건 또 보안상 문제인거같은데
어떻게 해야하는 거임?
세션이랑 JWT 방식이 뭔지 이해를 못한 것 같은데
세션이면 요청 마다 세션아이디 디비조회 하는데 jwt면 db 안거치고 받은 토큰 디코딩해서 유저 인가하는거 아님?
1. 너가 세션이랑 JWT가 어떻게 작동하는지 이해를 못 한 상황인것 같음. 2. UserDetails에서 loadUserByUsername으로 유저 정보를 조회하는것은 어디까지나 최초 인증시, 즉 로그인 시에 사용자 정보가 DB에 존재하는지 확인하는 과정임. 3. 인증 필터는 앞단에 위치한 JWT 토큰 검증 필터에서 검증에 성공하면 JWT 토큰 내 값을 기반으로 인증 정보가 시큐리티컨텍스트홀더에 채워지면, 뒤에 위치한 로그인 필터의 인증 메소드는 호출되지 않음. 4. 시큐리티에서 컨텍스트홀더는 스레드 로컬 기반으로 작동하기 때문에, 요청 스레드가 종료되면 소멸 대상임 5. JWT에 넣는 정보는 유저를 식별할 수 있으면서 동시에 그다지 쓸모가 없는 정보를 삽입함.
예를 들어 UUID필드를 유저 테이블에 두고 가입시 UUID 발급, 인증 성공 시 JWT 내에 UUID를 포함시킨다던가 하는 방식으로 유저를 유일하게 식별할 수 있음. 6. JWT 기반 인증에서 사용자가 유효한 토큰과 함께 요청을 전송하면, Jwt검증 필터에서 해당 jwt를 secret과 함께 검증 후 검증이 성공하면 컨텍스트에 Authentication객체를 채워두고, 컨트롤러에서 접근 가능하다고 이해하면 됨. 7. 이런 복잡성 때문에, 취준 과정에서는 스프링 시큐리티를 공부하는게 그다지 도움이 되지 않음.
일단 장문 답변 ㄱㅅㄱㅅ 이해 했음 5번에 정보로 닉네임 같은건 넣어도 됨? 나중에 쓸 일 있을거 같아서 - dc App
jwt 사용시에는 컨텍스트홀더에 컨텍스트-인증객체-userdetails를 채우고, 세션이든 jwt든 컨텍스트 홀더는 스레드로컬 기반이기 때문에 요청 끝나면 소멸, 세션 방식은 인증 이후 컨텍스트 객체는 세션에 저장되기 때문에 세션 만료 이전까진 별도 인증 없이 사용 가능한것
어떤걸 넣을지는 편한대로 하면 됨 민감정보만 아니면
난 니 말이 맞다고 생각함. 같은 취준생인데, 존재하는지 확인만 할거면 existby 썼겠지. 굳이 findby를? Jwt토큰은 payload에 진짜 최소한의 정보만 넣고 그 정보만을 신뢰하며 사용하는거임. 그게 불안하면 세션 쓰는거고.. 참고로 나도 저 블로그 글 본 기억이 있는데, 저 코드 보자마자 같은 생각으로 뒤로가기 누름.
스프링 시큐리티만 jwt 같이 쓸거면 userdetailservice 굳이 이용할 필요 없고 커스텀 authuser같은거 만들어서 거기다 payload 정보 넣어서 무상태로 쓰면됨.. db랑 통신할 필요 없이 내말이틀리다면 누가 반박해주먄 좋겠다