서비스 간 인증 실전: mTLS vs JWT, 어떤 경계에서 무엇이 맞나

서비스 간 인증 실전: mTLS vs JWT, 어떤 경계에서 무엇이 맞나

서비스 간 인증은 '누가 호출했나'를 증명하는 문제입니다. 방식은 팀의 경계에 따라 달라집니다.
mTLS와 JWT를 언제 어떤 조합으로 쓰는지 실무 기준으로 정리합니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

보안은 '켜면 끝'이 아니라, 환경(도메인/HTTPS/프록시)과 결합된 실제 동작이 중요합니다. 그래서 단계적 도입과 관측이 핵심입니다.

보안 설정은 예외가 생기기 쉬우므로, 예외를 '운영 프로세스'로 관리(만료/승인/감사)하지 않으면 시간이 지날수록 사고 확률이 커집니다.

실전 내용(바로 적용)

서비스 간 인증은 '누가 호출했나'를 증명하는 문제입니다. 방식은 팀의 경계에 따라 달라집니다.
mTLS와 JWT를 언제 어떤 조합으로 쓰는지 실무 기준으로 정리합니다.

핵심 요약(결론부터)

• 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
• 실패/예외/회귀를 운영 체크리스트로 막는다
• 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

결론(짧게)

네트워크 경계가 약하면 mTLS로 채널 인증
요청 단위 권한/클레임이 필요하면 JWT(또는 토큰)

운영 포인트

인증서 로테이션, 만료 알람은 필수
mTLS는 디버깅이 어렵기 때문에 관측/툴링이 중요

한 줄 요약

mTLS: 연결 레벨에서 상호 인증
JWT: 요청 레벨에서 클레임 전달

운영 체크리스트(바로 적용)

• 인증서 발급/배포/로테이션 자동화 계획을 먼저 만든다
• 토큰/클레임 정책(만료/권한)을 문서화한다
• 서비스 간 호출에 trace id를 전파해 디버깅을 가능하게 한다

FAQ

Q. 둘 중 하나만 골라야 하나요?
A. 아닙니다. mTLS로 채널 신뢰를 만들고, JWT로 요청 단위 권한을 표현하는 조합도 흔합니다.

마무리: 다음 액션

• 팀의 기본값(정책)을 1페이지로 문서화한다
• 대표 시나리오 1개를 코드/설정 예시로 고정한다
• 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

• 보안 설정을 일괄 적용하고, 깨지는 곳을 땜질한다(원인 추적이 불가능해짐)
• 테스트/로컬에서만 되는 설정을 프로덕션에 그대로 반영한다(도메인/HTTPS 차이)
• 민감정보(토큰/비밀번호)를 로그에 남겨 2차 사고를 만든다
• 예외를 무기한으로 두고, 소유자가 없는 정책을 만든다

적용 순서(추천)

• 1) 무엇을 막는지(위협 모델)를 한 줄로 적는다(CSRF/XSS/탈취/권한 상승 등)
• 2) 기본값을 보수적으로 정한다(예: Secure/HttpOnly/SameSite 등)
• 3) 예외는 만료일/사유/승인자를 남긴다
• 4) E2E로 확인한다(도메인/HTTPS/프록시 포함)
• 5) 보안 이벤트를 지표/알람으로 운영한다(로그인 실패, 권한 거부, 토큰 재사용 등)

검증/회귀 방지

• 브라우저 DevTools에서 쿠키/헤더가 실제로 어떻게 붙는지 확인
• 프록시 뒤에서 HTTPS 인식이 올바른지 확인(X-Forwarded-Proto 등)
• 민감정보가 로그에 남지 않는지 샘플링 점검

팀 합의 템플릿(복붙용)

# 운영 규칙 템플릿(복붙용)
기본 정책: (예) 쿠키 HttpOnly; Secure; SameSite=Lax
예외 정책: (예) SameSite=None 필요 시 Secure 필수
감사/승인: 정책 변경은 PR + 승인 필수
복구: 계정 잠김/2FA 분실/권한 오류 대응 절차 링크

FAQ

Q. 둘 중 하나만 골라야 하나요?
A. 아닙니다. mTLS로 채널 신뢰를 만들고, JWT로 요청 단위 권한을 표현하는 조합도 흔합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• RFC 8446: TLS 1.3
• RFC 7519: JWT