🤦🏻‍♀️고민하기 - Spring Security_API 경로에 따른 인증 및 역할 관리(2)

🌑 상황

1. 아래의 블로그를 보면 알 수 있듯이 API 네이밍 컨벤션 말고, 새로 알게 된 @PreAuthorize, @PostAuthorize을 써보기로 했는데 

Swagger UI까지 사용하다보니 Controller에 있는 메서드 상단에 붙어있는 어노테이션들이(아래의 사진처럼) 너무 많아지니까 불안(?)해졌다. 코드는 깔끔하고, 한눈에 보기 좋은 것이 미덕이라고 알고 있는데 부피가 커지는 것에 대한 막연한 걱정이 생긴 것이다. 

그래서 API 경로(인증이 필요 있는 API와 필요 없는 API의 구분)에 따른 인증 방법에 대해서 "다시"고민해보았다.

 

2. 그리고 API 경로 자체도 딱! 규칙을 정해서 일관되게 하고 싶은데, controller마다 제각각인 느낌이라 이 부분도 확실히 잡고 넘어가려고 한다~~ 

 

https://grogrammer.tistory.com/120

🤦🏻‍♀️고민하기 - Spring Security_API 경로에 따른 인증 및 역할 관리(1)

 

@PreAuthorize을 적용한 코드

 

---

🌗 과정

메서드 단위(@PreAuthorize, @PostAuthorize)로 인증 여부를 적용하면
메서드가 한 두 개일 때는 상관없지만 많아지기 시작하면 코드가 너저분 해질 거 같았다.

✚

프런트와 협업할 때 해당 요청이 인증이 필요한지 여부에 대해 파악하기가 어려울 거 같았다.

➡️

이를 모두 해결할 수 있는 방법은 돌고 돌아 다시 API 네이밍 컨벤션 방식이라는 결론을 내렸다 ^0^

 

아, 그리고 더욱 검색하여 알아보니 메서드 단위 어노테이션은 전체 인증을 통제하기보다는 역할(role) 별로 메서드 수행 여부를 통제할 때 쓰는 게 더욱 적합해 보인다는 생각이 들었다. 

 

---

🌕 결론

API 경로로, rest api를 기본으로 사용하되, 인증이 필요한 작업과 인증이 필요하지 않은 작업에 대해 경로를 조금씩 다르게 설정하는 방법으로 아래와 같은 방식으로 적용해 볼 것이다.

팀 기능의 GET 요청 ➡️ 인증 없이 접근할 수 있도록 ➡️ /api/public/teams/

팀 기능의 CUD 요청 ➡️ 인증을 요구하도록 ➡️ /api/teams

 

대부분은 로그인을 해야지 실행할 수 있는 기능들일 것이기 때문에 인증이 필요가 없는 몇몇 기능에만 /public을 붙여서 구분해보고자 한다.

 

이 과정에서 새로 알게 된 사실이 하나 있다.

 

/api/를 경로에 포함시키면 좋은 이유??

API 엔드포인트와 웹 애플리케이션의 다른 리소스를 명확하게 구분하기 위함으로
예를 들어, 웹 애플리케이션에서는 HTML, CSS, JavaScript 같은 파일을 제공하는 경로와 API 요청을 처리하는 경로가 다르게 처리할 수 있다. 

• 웹 리소스 경로 : /about, /content
  ➡️ 사용자가 직접 웹페이지에 접근하는 경로
• API 경로 : /api/teams, /api/users
  ➡️ 클라이언트가 데이터를 요청하거나 전송하기 위한 경로
  

이처럼 /api/ 를 포함시킴으로써, 사용자는 이 경로가 데이터를 처리하는 API임을 쉽게 알 수 있고, 웹페이지 요청과 API 요청을 분리해 관리할 수 있다. 즉, /api/는 애플리케이션의 "데이터 전공"과 "페이지 제공" 역할을 구분하는데 도움이 되는 네이밍 관례이다.