최초 개발에서, 스프링 시큐리티의 복잡성에 불편함을 느껴 인터셉터 기반의 인증을 적용했었습니다. 인터셉터 기반으로 적용했기 때문에 @Auth 어노테이션을 통해 코드상에서 인증이 필요한 API를 쉽게 확인할 수 있었고 스프링 시큐리티보다 수월하게 적용할 수 있었지만, 문제도 있었습니다. 특정 리소스에 write하는 API은 자신의 리소스에만 호출할 수 있도록 검증 작업이 필요했기 때문에 @OwnResource 을 통해 추가적인 인터셉터 로직을 추가해야됐고 요청마다 다른 소유자 id 검증 때문에 꽤나 지저분한 코드가 작성됐습니다.
이외에 토큰 기반 인증 방식도 토큰의 장점을 제대로 취하지 못하는 형태로 적용했었습니다. 리프레쉬 토큰을 서버측(레디스)에 저장하게 되면서 세선 기반의 단점을 토큰이 가져와버리는 문제가 발생하여 확장성에 걸림돌이 됐습니다.
스프링 시큐리티를 적용하여 인증 필터를 통해 토큰을 발급하고 인증이 필요한 API에서 jwt필터를 거치도록하여 인증을 적용했습니다. 또한 자신의 리소스에만 write요청을 할 수 있도록하는 검증 작업이 필요했는데 @PreAuthorize를 활용하여, 이전보다 비교적 수월하게 적용할 수 있었습니다.
기존에 적용되어있던 방식은 다음과 같습니다.
위 방식에는 크게 두 가지 문제점이 있었습니다.