feat: jwt 검증 및 처리 resolver와 interceptor에 위임

[Hejow]

🙋 어떤 PR인가요?

기존에 퍼져있던 토큰 검증 로직을 스프링을 적극 사용해서 개선하였습니다.

📝 작업 상세

1. 토큰 검증 추상화

기존에 JwtAgent가 모든 컨트롤러에 위치해서 제한된 유저인지 검증했습니다. presentation layer의 핵심 관심사이나 너무 많은 중복된 코드가 발생하여 interceptor에서 처리하도록 수정하였습니다.

Controller에 다음과 같이 어노테이션이 붙어있다면 앞으로 헤더에 토큰을 넣어줘야함(인증이 수반되어야함)을 의미합니다.

@Authorize
public ApiResponse<?> someApi() {
   // logic...
}

또한, 관리자 API에 대해서는 다음과 같이 사용하면 관리자의 토큰이 아닐 때 예외 응답합니다.

@Authorize(Role.ADMIN)
public ApiResponse<?> someAdminApi() {
   // logic...
}

권한을 모듈 별로 따로 만들지 않고 기존 것을 사용하는게 추후 확장에 따라 발생할 수 있는 휴면 에러를 방지할 수 있다고 판단하였습니다. 그로 인해서 인증 core에서 사용자 모듈로 의존성이 추가되었습니다.

2. 유저 ID 파싱 추상화

1번과 비슷한 맥락으로 JwtAgent가 각 컨트롤러에 퍼져있거나, 서비스 계층까지 침투하고 있었습니다. 이런 현상을 방지하고자 AuthenticatedUserArgumentResolver을 도입해 중복된 코드를 줄이고 한 지점에서 관리할 수 있도록 하였습니다.

앞서 설명한 @Authorize 어노테이션 없이 사용할 시에 인증이 완료되지 않아 예외를 반환합니다. 사용법은 다음과 같습니다.

@Authorize
public ApiResponse<?> someApi(@Login Long userId) {
   // logic...
}

3. 과한 책임의 TokenAgent 개선

기존 TokenAgent는 너무 많은 책임을 담당하고 있었기 때문에 필요없는 책임은 모두 없앴습니다. 실질적인 구현체인 JwtAgent는 모듈을 auth-core에서 auth-token 쪽으로 이동시켜서 내부적으로 사용되고 외부는 TokenAgent로만 노출을 할 수 있도록 정보 은닉을 진행할 예정입니다.

🙏 To Reviewers

• 유저 정보를 불러오기 위해서 UserDetailsService를 추가하였습니다. 모듈 구조로 인해서 어쩔 수 없이 user 모듈 쪽에 추가적인 클래스가 반영되었습니다. 이 부분은 추후 개선해보겠습니다~
• 적용되지 않던 security 설정이 반영되었습니다. 이로 인해서 테스트 시 문제가 발생할 수 있으니 참고바랍니다!

🧐 체크리스트

• [x] 본인을 Assign해주시고, 본인을 제외한 백엔드 개발자를 Reviewer로 지정해주세요.
• [x] 라벨 체크해주세요.
• [x] .yml 파일 수정 내용이 있다면 공유해주세요!
• [x] 정상동작하는지, 테스트 통과하는지 다시 한번 확인해주세요.