인증 로직 구현 과정에서의 논의 사항

[helenason]

카카오톡에서 나눈 이야기를 요약하였습니다.

1. 인증 관련 네이밍 정리

• 향후 기본 로그인 추가 가능성을 고려하여 oauth 대신 auth 사용 제안.
• API 경로 예시
  • 소셜 로그인 → /api/auth/login/kakao
  • 기본 로그인 → /api/auth/login/basic
• 클래스 구조 예시
  • 기존: OAuthController > OAuthService > (OAuth 관련 클래스들)
  • 제안: AuthController > AuthService > (OAuth 클래스 & 기본 로그인 클래스 분리)

2. 에러 코드 위치 조정

• 에러 코드 패키지를 global이 아닌 각 feature 내에서 선언하는 방향 제안.
• 기존: global > exception > [feature]
• 제안: [feature] > exception
• 이유: 에러 코드는 feature별로 사용되며, global에 두면 불필요한 계층 구조가 생김.

3. Security 패키지 위치 조정

• 기존: security 패키지가 global 내에 위치
• 제안: AuthFilter, TokenProvider 제외한 모든 security 관련 클래스 feature > auth로 이동
• 이유
  • 현재 우리의 security 패키지는 전체적인 global이 아닌 auth 피처 패키지에서만 사용됨
  • 클래스 검색 시 feature 내부에 있는 것이 더 자연스러움

4. 최상단 인증 로직 filter → interceptor 변경 제안

• 상황: 에러 응답 바디 형식 통일 필요

  response.sendError(HttpServletResponse.SC_UNAUTHORIZED, ex.getMessage());

• 기존: filter를 통해 최상단에서 인증 여부 검증
• 제안: Interceptor를 통해 최상단에서 인증 여부 검증
• 이유
  • Interceptor는 SpringContainer의 DispatcherServlet 이후에 동작하므로, 요청에 대해 더 상세한 정보를 확인할 수 있음 (특히 다른 비즈니스 로직과 같이 GlobalExceptionHandler 활용이 가능하다는 점)
  • Filter에서 sendError를 호출하는 방식보다, Interceptor를 활용하여 공통된 응답 바디를 처리하는 것이 더 일관적일 수 있음.
  • 필터와 인터셉터 사이에 인증 관련 로직이 존재하는 경우, 반드시 필터에서 처리해야 하지만, 그렇지 않다면 인터셉터에서도 충분히 가능

5. 커스텀 예외 - TookException

• 기존: 여러 개의 커스텀 예외
• 변경 제안: 하나의 커스텀 예외로 통합 ( == 내가 초기 의도한 방향 )
  • 내가 생각하는 커스텀 예외의 목적: “방대한 표준 예외 관리 어려움” + “서비스 내에서 의도한 예외임을 드러내기 위함”
  • 기존의 방법은 위 목적을 흐린다고 생각
  • ErrorCode만으로도 예외의 목적은 충분히 전달 가능
  • 불필요한 커스텀 예외가 많아지면 유지보수성 저하됨

[helenason]

경호

1. 찬성

2. 찬성

• CommonErrorCode에 대해 feature>common>exception 위치를 제안

3. 찬성

4. filter 주장

• 요청을 가장 앞단에서 막을 수 있다는 점이 장점.
• 일반적으로 인증/인가는 Filter에서 처리하는 것이 일반적이므로, 자연스럽게 Filter를 선택.
• Filter는 보안 및 성능상 이점이 있음.
  • 요청이 DispatcherServlet까지 가지 않고 차단 가능 → 불필요한 리소스 낭비 방지.
  • 클라이언트에서 잘못된 요청을 보낸 경우, 빠르게 차단할 수 있음.

[ Filter 유지가 적절한 경우 ]

• 인증/인가 같은 보안 관련 로직이 포함되어 있는 경우.
• 요청을 가장 빠르게 차단해야 하는 경우 (불필요한 컨트롤러 접근 방지).
• DispatcherServlet까지 가기 전에 로직을 수행하는 것이 성능적으로 더 유리한 경우.

[ Interceptor로 변경이 유리한 경우 ]

• 요청/응답 데이터를 조작할 필요가 있는 경우.
• 예외 처리를 통합해서 관리하고 싶은 경우.
• 필터와 인터셉터 사이에서 인증을 처리하는 별도의 로직이 존재하지 않는 경우.

5. 찬성

[helenason]

찬기

1. 찬성

2. 찬성

• TookException 도 함께 common 폴더로 옮길 것을 제안

3. 찬성

• AccessToken Validation 이 Auth 뿐만 아니라 다른 feature 패키지에서도 활용이 될 것 같아 auth feature 에 security 관련 클래스를 종속시키는 것이 우려가 됨
• (채영) 로그인 사용자를 판단하는 로직을 말씀하시는 거라면 ArgumentResolver로 뽑아 구현할 수 있어서 다른 피처에서 사용되진 않을 것 같음
• (찬기) 찬성

4. filter 주장

• Interceptor의 경우, DispatcherServlet 이후에 실행되어 일부 정적 리소스나 특정 요청은 인증 처리 이전에 실행되는 문제가 있다는 것이 치명적일 것 같고, 우리가 사용하진 않았지만 Spring Security 도 사실 Filter 기반으로 동작하고, Filter는 DispatcherServlet 이전에 실행되어 모든 요청에 대해 인증 검사가 가능하다보니 Filter 가 더 좋을 것 같음

5. 찬성