피드로 돌아가기
Why we built an Auth Gateway instead of putting auth in every service
Dev.toDev.to
Security

Auth Gateway 도입을 통한 30개 서비스 인증 로직 중앙화 및 Fail-Closed 보안 강화

Why we built an Auth Gateway instead of putting auth in every service

Akarshan Gandotra2026년 5월 4일9intermediate

Context

서비스별 Auth Library 도입으로 인한 버전 파편화 및 CVE 대응 지연 문제 발생. 개별 서비스의 자의적 인증 구현에 따른 보안 일관성 결여와 비정상 토큰 처리 미흡이라는 구조적 한계 직면.

Technical Solution

  • NGINX의 auth_request 모듈을 활용하여 Edge 단에서 인증을 결정하는 중앙 집중형 구조 설계
  • Authentication, Authorization, Routing의 책임을 NGINX와 별도 Auth Service로 분리하여 상호 의존성 제거
  • NGINX가 Auth Service에 POST 서브리퀘스트를 전송하여 토큰 유효성 및 권한을 검증하는 메커니즘 구축
  • 검증 완료 후 auth_request_set을 통해 Identity 헤더를 주입하여 Upstream 서비스의 JWT 처리 부담 제거
  • Fail-Closed 포스처를 적용하여 인증 실패 시 Upstream 호출을 원천 차단하는 보안 강화 설계
  • Helm Chart 기반의 설정 자동화로 새로운 서비스 추가 시 인프라 전문가 없이 설정 변경만으로 연동 가능

- 서비스 규모 확장 시 공유 라이브러리 방식보다 사이드카나 게이트웨이 기반의 중앙 집중형 인증 검토 - 인증 실패 시 서비스 내부로 요청이 전달되지 않도록 하는 Fail-Closed 구조 적용 여부 확인 - Upstream 서비스가 JWT를 직접 파싱하지 않고 신뢰할 수 있는 헤더(Identity Header)만 사용하도록 추상화 - 인증/인가/라우팅의 책임을 명확히 분리하여 변경 영향도를 최소화하는 책임 분리 원칙 적용

원문 읽기