Forward Auth: API Gateway의 인가 위임 방식

TL;DR
Forward Auth는 API Gateway가 요청을 백엔드로 전달하기 전에 외부 인증/인가 서비스에 서브리퀘스트로 판정을 위임하는 방식입니다.
파일 스트리밍 등 데이터 전송 구간을 Auth 서비스가 경유하지 않아 대역폭 병목이 발생하지 않습니다.

파일 서비스를 만들면서 API Gateway 사용이 전제로 주어졌습니다. GW 뒤에 인가 서비스를 두는 일반적인 프록시 구성에서는 모든 요청이 바디까지 인가 서비스를 경유합니다. 파일 업로드/다운로드가 주 트래픽인 서비스에서는 인가 서비스의 처리량이 전송 대역폭을 제한하는 병목이 됩니다.

데이터 경로에서 인가 서비스를 분리하고 판정 로직만 별도로 두는 방법을 찾다가 알게 된 것이 Forward Auth라고 부르는 방식입니다.
GW 환경에서 스트리밍 병목을 어떻게 풀지 고민하다 도달한 해결책이었을 뿐 이 방식 자체가 전제였던 것은 아니었습니다.

개념 정의

Forward Auth는 Gateway가 직접 인증/인가를 처리하지 않고 별도 서비스에 “이 요청을 허용할까요?”라는 서브리퀘스트를 보내는 위임 구조입니다.

핵심은 데이터 경로와 인가 경로의 분리입니다.

[일반 프록시]
Client → GW → Auth → Backend     ← Auth가 데이터 경로에 있음

[Forward Auth]
Client → GW ─┬→ Auth (서브리퀘스트, 판정만)
              └→ Backend (원본 요청 전달)  ← Auth가 데이터 경로에 없음

용어 참고: 같은 개념을 Traefik·APISIX·Caddy·Kong은 forward-auth 계열, nginx는 auth_request, Envoy는 ext_authz로 각각 구현합니다.
이 글은 APISIX를 선택해 forward-auth를 채택한 사례라 “Forward Auth”라는 이름을 따릅니다.

동작 흐름

1. Client → GW        : 원본 요청 도착
2. GW → Auth           : 서브리퀘스트 (헤더만 전달, 바디 미포함)
3. Auth → GW           : 200 OK (허용) 또는 401/403 (거부)
4. GW → Backend        : 허용 시 원본 요청 그대로 전달

• 2번에서 GW는 요청 바디를 Auth로 보내지 않습니다. 헤더(Authorization, Cookie 등)만 전달합니다.
• Auth의 응답 헤더를 백엔드에 전파할 수 있습니다. (예: X-User-Id, X-Permissions)
• 거부 시 GW가 클라이언트에 직접 에러를 반환합니다.

스트리밍과 병목

이 구조에서는 GW가 인가 서비스에 보내는 것이 헤더뿐이고 판정 후 원본 요청(바디 포함)은 백엔드로 직접 전달됩니다.
파일 업로드/다운로드의 스트리밍 데이터는 인가 서비스를 경유하지 않으므로 인가 서비스의 처리량이 전송 대역폭에 영향을 주지 않습니다.

도입부에서 제기한 “인가 서비스가 데이터 경로에 위치해 대역폭을 제한하는 문제”는 판정을 데이터 경로에서 분리한 이 구조로 해소됩니다.

적용 사례: 파일 서비스

실무에서는 이 방식을 “쓸까 말까” 판단하기보다, 전제된 환경에서 어떻게 설계할까를 고민하는 경우가 더 많다고 봅니다. 앞서 언급한 파일 서비스 사례에서도 상위 플랫폼의 인가 체계를 재사용해야 하는 제약이 있었고 그 제약상 API Gateway 레벨 forward-auth가 출발점으로 주어졌습니다. 파일 서비스는 폐쇄환경의 승인된 사용자만 접근하는 B2B 성격이라 트래픽 성격이 정적입니다. 전체 요청 경로는 아래와 같습니다.

Browser → LB → GW ─┬→ 플랫폼 Authz (인가 확인)
                    └→ 파일 서비스 BE (파일 전송)

GW는 forward-auth로 플랫폼 Authz에 경로·Role 판정을 위임하고 판정이 허용되면 원본 요청을 파일 서비스 BE로 그대로 전달합니다.

결과

이 구성에서 확인된 것과 내린 운영 결정입니다.

• 스트리밍 병목 회피: 파일 전송량이 증가해도 인가 서비스의 처리량이 전송 대역폭 상한을 만들지 않습니다.
• BE의 단일 책임 유지: 파일 서비스 BE에 인가 로직이 포함되지 않아 인가 정책 변경이 BE 배포와 분리됩니다.
• 장애 정책 (fail-close + 서킷 브레이커): 인가 서비스 장애 시 차단(fail-close)을 기본으로 두고 서킷 브레이커 패턴으로 장애 영향이 다른 경로로 전파되지 않도록 격리합니다. 부분 허용·재시도 같은 정교한 fallback은 GW 추가 구성·관측 비용이 상당해 현재 운영 여건에서는 수용 가능한 수준의 정책으로 유지합니다. 일시적 Auth 장애로 유효 세션이 끊기는 UX 비용은 서비스 특성상 허용 범위로 봅니다.

이 글은 Claude와 함께 작업했습니다.