인증(Authentication)은 “누구냐” 문제 → Filter
권한(Authorization)은 “이 요청을 해도 되냐” 문제 → Interceptor

이건 관습이 아니라 구조적 필연입니다.


1️⃣ 인증을 Filter에 두는 이유 (구조 레벨)

인증의 본질

  • 요청을 보낸 주체 확인
  • 토큰, 세션, 쿠키 검증
  • 실패하면 즉시 차단

👉 Spring에 들일 가치가 있는 요청인가? 판단


Filter가 맞는 이유

① Spring 밖에서 막아야 함

  • 인증 실패 요청은
    • 컨트롤러
    • 서비스
    • 트랜잭션
      전부 탈 자격 없음

DispatcherServlet까지 갈 이유 자체가 없음


② 기술적 특성

  • HTTP 헤더 기반 (Authorization)
  • Stateless (JWT)
  • 공통 규칙 (모든 URL)

Servlet Container 레벨이 최적


③ 보안 사고 방지

  • 인증을 Interceptor에 두면:
    • 컨트롤러 매핑됨
    • Argument Resolver 실행됨
    • 불필요한 객체 생성 발생

👉 공격 표면이 커짐


인증 Filter의 정석 역할

 
요청 → 토큰 있음? 유효함? 위조 아님? 만료 안 됨? → 아니면 즉시 401

2️⃣ 권한을 Interceptor에 두는 이유 (의미 레벨)

권한의 본질

  • 인증된 사용자
  • 이 URL / 이 기능을
  • 지금 실행해도 되나?

👉 맥락(Context) 판단 문제


Interceptor가 맞는 이유

① Handler 정보가 필요함

권한 판단에는 보통 필요:

  • 어떤 컨트롤러?
  • 어떤 메서드?
  • 어떤 HTTP Method?
  • 어떤 @Annotation?

이 정보는
HandlerMapping 이후에만 존재

Filter 단계에서는 모름


② Spring Bean 접근 필요

권한은 보통:

  • DB 조회
  • 정책 서비스
  • Role/Permission 매핑

Spring Bean 필요
➡ Filter에서는 구조적으로 불리


③ Controller 단위 제어

  • /admin/**
  • /user/{id}
  • 메서드별 권한

➡ URL 패턴보다 Handler 단위 제어가 정확


Interceptor 권한 체크 예시

 
if (!hasPermission(user, handlerMethod)) { throw new AccessDeniedException(); }

3️⃣ 왜 AOP는 권한에 안 쓰나?

AOP는 너무 늦음

AOP는:

 
Controller → Service 호출 시

이미:

  • 컨트롤러 진입
  • 파라미터 바인딩 완료
  • 일부 로직 실행 가능

👉 보안 관점에서 늦다


AOP가 적합한 경우

  • 내부 비즈니스 규칙
  • 도메인 보호
  • 이중 방어

예:

  • “본인 데이터만 수정 가능”
  • “관리자라도 승인 필요”

2차 방어선


4️⃣ 한 방에 보는 책임 분리

 
[Filter] 너 누구냐? ↓ [Interceptor] 이 요청 해도 되냐? ↓ [Controller] 요청 처리 ↓ [Service/AOP] 이 행위가 합법이냐?

5️⃣ 실무에서 어기면 생기는 문제

❌ 인증을 Interceptor에 둔다

  • 불필요한 Spring 객체 생성
  • 공격 표면 증가
  • 성능 낭비

❌ 권한을 Filter에 둔다

  • Handler 정보 없음
  • URL 기반 허술한 제어
  • 메서드 단위 통제 불가

❌ 권한을 AOP로만 처리

  • 이미 늦음
  • 보안 사고 시 변명 불가

6️⃣ 면접에서 쓰는 정답 문장

인증은 Spring 진입 전 차단해야 하므로 Filter가 적합하고,
권한은 Handler 정보와 비즈니스 맥락이 필요하므로
DispatcherServlet 내부의 Interceptor가 적합합니다.


최종 요약 (암기용)

  • 인증 = 입장권 → Filter
  • 권한 = 좌석 확인 → Interceptor
  • 규칙 = 경기 중 반칙 → AOP
LIST

+ Recent posts