Closed yarogono closed 1 year ago
토큰 탈취를 대비해서 Refresh 토큰 대신에 유저의 IP를 통해 검증을 해는 방법도 괜찮을까요?
-> 좋지 않다고 생각합니다. 최근 대부분 앱이나 웹이 다중 로그인을 허용하는데 IP는 그 기반 정보가 되기 좋지 않습니다.
토큰에 유저 정보를 최대한 줄여서 username만 넣었는데 괜찮을까요?
-> username에대한 변경 기능을 제공하지 않을 예정이라면 그렇게 해도 괜찮습니다.
몇가지 이해가 잘 안가는 부분이 있어서, 밤에 리뷰할게요!
심플하게 포인트를 짚을 수 있으면 위 코멘트 보고 바로 하려했는데, 돌려보면서 체크하고 싶은 것도 좀 있고해서 그렇습니다.
혹시 시간 나실 때 plantuml (sequence diagram) 그려주실 수 있나요? 인증 관련
시간이 잘 안나시면 괜찮습니다.
몇가지 이해가 잘 안가는 부분이 있어서, 밤에 리뷰할게요!
심플하게 포인트를 짚을 수 있으면 위 코멘트 보고 바로 하려했는데, 돌려보면서 체크하고 싶은 것도 좀 있고해서 그렇습니다.
혹시 시간 나실 때 plantuml (sequence diagram) 그려주실 수 있나요? 인증 관련
시간이 잘 안나시면 괜찮습니다.
네! 7시까지 알바 일 처리 완료 후에 그리도록 하겠습니다.
주로 참고했던 자료들이 총 3개인데 그것도 공유 드려도 괜찮을까요? Spring Security Flow 관련해서 아직 감이 안잡히는게 좀 있어서요.
넵 공유 주시면 확인해보겠습니다.
제가 접해온 flow랑 다른 것들이 좀 있는데, 이 것이 어떤 것인지 볼려면 동작보면서 좀 살펴봐야 할 거 같아서 일끝내고 면밀히 보고자 리뷰가 조금 시간이 걸릴 거 같아요.
대략 8시쯤에는 볼 수 있을 거 같아요!
시퀸스 다이어그램은 그리는데 좀 걸릴 것 같아서 참고한 자료부터 공유드리겠습니다.
혹시 해당 로그인 처리를 어떤 방식으로 테스트 해보셨을까요?
성공 케이스 시퀀스 다이어그램 그려봤습니다.
넵~ 이해는 되었고, 조금만 더 살펴보고 피드백 드릴게요!
성공 케이스 시퀀스 다이어그램 그려봤습니다.
시퀀스 다이어그램은 쟁여 두었다가 README와 블로그 등에 활용하면 좋을 거 같고, 발급만이 아니라 인증 성공, 인증 실패도 다이어그램이 있으면 유용할 거같습니다.
스프링 시큐리티를 활용하면서 복잡한 모양새로 구현 된 거 같아요.
https://devbksheen.tistory.com/entry/Spring-Security-JWT
요 분 블로그가 스프링 시큐리티를 심플하게 쓰지 않고 복잡하게 썼는데 영향을 받으신 거 같아요.
https://github.com/ali-bouali/spring-boot-3-jwt-security 요 분이 좀 더 심플하게 잘 구현하셨다고 생각하지만 이미 구현된 내용이니 요 부분은 첨언만 하고 패스하겠습니다.
스프링 시큐리티를 활용하면서 복잡한 모양새로 구현 된 거 같아요.
https://devbksheen.tistory.com/entry/Spring-Security-JWT
요 분 블로그가 스프링 시큐리티를 심플하게 쓰지 않고 복잡하게 썼는데 영향을 받으신 거 같아요.
https://github.com/ali-bouali/spring-boot-3-jwt-security 요 분이 좀 더 심플하게 잘 구현하셨다고 생각하지만 이미 구현된 내용이니 요 부분은 첨언만 하고 패스하겠습니다.
네 구현을 하면서 직접 SuccessHandler를 타서 Response를 보내야 하는게 아닐까? 하다가 위와 같이 구현을 했네요(블로그 보고 구현한 것). 생각해보니까 login 관련 requestMapping 컨트롤러를 만들어서 토큰을 generate 해주는 방식이 더욱 간결하고 좋은 것 같네요. 보완점을 보완 후에 커밋 하겠습니다. (저도 수정을 하는게 Exception 처리도 편하고, 코드가 깔끔해 질 것 같다고 생각하네요.) 감사합니다 멘토님
Spring Security 로직 간소화
JWT 토큰을 헤더로 전달하던 방식에서 쿠키 방식으로 변경
JwtAuthenticationFilter Exception 처리
현재까지의 방향성에서의 1차적인 구현은 좋은 거 같습니다. 구현도 훨씬 심플해졌고요.
몇가지 포인트만 더 고민해보면 될 거 같네요.
수고하셨습니다.
현재까지의 방향성에서의 1차적인 구현은 좋은 거 같습니다. 구현도 훨씬 심플해졌고요.
몇가지 포인트만 더 고민해보면 될 거 같네요.
- 토큰이 만료되면 어떻게 할 것인가?
- 로그인을 다시 시킬 것인가?
- 매번 사용자에게 로그인 flow를 태울 것인지 여부
- 중복 로그인 처리
- 정책적으로 용인해도 무방하긴 하지만, 현재는 유효한 토큰을 보유했을 경우 만료 시간까지 무제한 사용 가능
- 허용하지 말자는 의미가 아닌, 검토 대상에서 고려 되었는지에 대한 확인
- 만약 중복 로그인을 막아야 한다면 어떻게 할 것인가? (이것도 실제로 하자는 것이 아닌, 방법을 고민해보면 좋을 것 같음)
수고하셨습니다.
감사합니다 멘토님! 해당 내용에 대해서 고민해보고 차 후에 보완해보겠습니다 😄
Checklist
작업내용
Questions
💬 질문 사항이에요!
토큰 탈취를 대비해서 Refresh 토큰 대신에 유저의 IP를 통해 검증을 해는 방법도 괜찮을까요?
토큰에 유저 정보를 최대한 줄여서 username만 넣었는데 괜찮을까요?
🤷♂ ️확인 받고 싶은 부분이에요!