본문으로 건너뛰기

인증 패턴

개요​

DTA-WIDE 시스템은 마이크로서비스 아키텍처를 기반으로 하며, 다양한 인증 패턴을 통해 보안성과 확장성을 보장합니다. 이 문서는 시스템에서 사용되는 주요 인증 패턴들과 각각의 적용 사례를 설명합니다.

인증 패턴 분류​

1. Service-to-Service Authentication (서비스 간 인증)​

정의: 마이크로서비스 간의 내부 통신에서 사용되는 인증 방식입니다.

특징:

  • API Key + JWT Token 조합 사용
  • Google Service Account 방식과 유사
  • 장기 자격 증명(API Key) + 단기 액세스 토큰(JWT)

적용 사례:

구현 방법:

  • 각 서비스는 고유한 API Key 보유
  • JWT 토큰을 통한 단기 인증
  • 토큰 자동 갱신 메커니즘

현재 구현 프로젝트:

  • dta-wide-api: 서비스 간 내부 API 호출에 사용
  • dta-wide-agent-qa: QA 에이전트의 시스템 리소스 접근
  • dta-wide-mcp: 시스템 레벨 MCP 툴 (로그 조회, 메트릭 수집)

2. User Token Delegation Pattern (사용자 토큰 위임)​

정의: 중간 서비스가 사용자를 대신하여 토큰을 관리하고 API 호출을 수행하는 패턴입니다.

특징:

  • 클라이언트 복잡성 감소
  • 중앙화된 토큰 관리
  • 자동 토큰 갱신

적용 사례:

현재 구현 프로젝트:

  • dta-wide-mcp: MCP Server에서 Chat Service의 사용자 토큰을 위임받아 dta-wide-api 호출
    • TokenManagerService: 사용자별 토큰 저장 및 자동 갱신
    • ApiClientService: 토큰 기반 HTTP 클라이언트
    • McpToolsService: 사용자 개인 데이터 접근 툴 제공

장점:

  • 클라이언트는 토큰 만료 처리 불필요
  • 중앙화된 토큰 관리로 보안성 향상
  • 자동 재시도 및 오류 처리

단점:

  • 중간 서비스의 복잡성 증가
  • 토큰 저장 및 보안 고려사항
  • 추가적인 네트워크 홉

3. API Gateway Authentication (API 게이트웨이 인증)​

정의: API Gateway에서 모든 인증을 처리하고 백엔드 서비스로 전달하는 패턴입니다.

특징:

  • 중앙화된 인증 처리
  • 백엔드 서비스는 인증 로직 불필요
  • 횡단 관심사 분리

적용 사례:

현재 구현 프로젝트:

  • 계획 중: 향후 외부 API 노출시 API Gateway 패턴 적용 예정
  • dta-wide-api: 일부 엔드포인트에서 중앙화된 인증 미들웨어 사용

4. Direct User Authentication (직접 사용자 인증)​

정의: 클라이언트가 직접 인증 서버와 통신하여 토큰을 관리하는 전통적인 방식입니다.

특징:

  • 클라이언트가 모든 토큰 관리 책임
  • 직접적인 통신으로 지연 시간 최소화
  • 클라이언트 복잡성 증가

적용 사례:

현재 구현 프로젝트:

  • dta-wide-api: 모바일 앱 및 웹 클라이언트의 직접 인증
    • /auth/login, /auth/refresh 엔드포인트 제공
    • JWT 기반 액세스 토큰 및 리프레시 토큰 발급

패턴별 비교​

패턴복잡성보안성성능확장성적용 사례
Service-to-Service중간높음높음높음내부 서비스 통신
User Token Delegation높음높음중간높음MCP Server, BFF
API Gateway중간높음중간높음외부 API 노출
Direct User Auth낮음중간높음중간단순한 클라이언트

토큰 생명주기 관리​

토큰 저장 전략​

메모리 기반 저장:

  • 빠른 액세스
  • 서버 재시작시 손실
  • 확장성 제한

Redis 기반 저장:

  • 영속성 보장
  • 분산 환경 지원
  • 네트워크 오버헤드

데이터베이스 저장:

  • 완전한 영속성
  • 감사 로그 지원
  • 성능 오버헤드

토큰 갱신 전략​

사전 갱신 (Proactive Refresh):

// 만료 5분 전 자동 갱신
if (token.expiresAt - Date.now() < 5 * 60 * 1000) {
  await refreshToken(token);
}

반응적 갱신 (Reactive Refresh):

// 401 에러 발생시 갱신 후 재시도
try {
  return await apiCall(token);
} catch (error) {
  if (error.status === 401) {
    const newToken = await refreshToken(token);
    return await apiCall(newToken);
  }
  throw error;
}

보안 고려사항​

토큰 암호화​

  • 저장시 토큰 암호화 필수
  • AES-256-GCM 권장
  • 키 순환 정책 적용

감사 로깅​

  • 모든 토큰 작업 로깅
  • 사용자별 토큰 사용 추적
  • 비정상적인 패턴 감지

토큰 순환​

  • 정기적인 토큰 갱신
  • 의심스러운 활동시 즉시 무효화
  • 세션 종료시 토큰 정리

구현 가이드라인​

1. 패턴 선택 기준​

User Token Delegation을 선택하는 경우:

  • 클라이언트가 단순해야 하는 경우
  • 중앙화된 토큰 관리가 필요한 경우
  • 여러 백엔드 서비스 호출이 필요한 경우

Direct Authentication을 선택하는 경우:

  • 단순한 클라이언트-서버 구조
  • 최소한의 지연 시간이 중요한 경우
  • 클라이언트가 토큰 관리 능력을 갖춘 경우

2. 오류 처리 전략​

class AuthenticationError extends Error {
  constructor(
    message: string,
    public readonly code: string,
    public readonly retryable: boolean = false
  ) {
    super(message);
  }
}

// 재시도 가능한 오류
throw new AuthenticationError('Token expired', 'TOKEN_EXPIRED', true);

// 재시도 불가능한 오류
throw new AuthenticationError('Invalid credentials', 'INVALID_CREDENTIALS', false);

3. 모니터링 및 알림​

핵심 메트릭:

  • 토큰 갱신 성공률
  • 인증 실패율
  • 평균 토큰 생명주기
  • API 호출 지연 시간

알림 조건:

  • 토큰 갱신 실패율 > 5%
  • 인증 실패율 > 10%
  • 비정상적인 토큰 사용 패턴 감지

관련 문서​