LLM 게이트웨이를 위한 5가지 인증 방식 가이드

섹션별 상세

대부분의 LLM 클라이언트가 baseURL과 apiKey라는 제한된 인증 방식만을 지원하여 기업용 게이트웨이 도입 시 인증 구현에 어려움이 발생한다. MCP와 같은 프로토콜은 OAuth 2.1과 PKCE 등 고도화된 인증 체계를 갖추고 있으나, 일반적인 LLM 클라이언트는 여전히 단순한 Bearer 토큰 구조에 의존하고 있다.

근거

Archestra v1.2.33은 기본 방식부터 고급 방식까지 5가지 LLM 프록시 인증 방법을 지원한다. — Archestra v1.2.33: Support All of Them 섹션

Direct Provider Key 방식은 호출자가 실제 제공자의 API 키를 프록시 경로로 직접 전달하며, Archestra는 이를 전달하면서도 로깅과 정책을 적용한다. 이 방식은 구현이 가장 간단하여 로컬 테스트나 단순 스크립트에 적합하지만, 자격 증명 격리가 불가능하여 모델 라우터와는 함께 사용할 수 없다.

Virtual API Key는 Archestra가 발행한 토큰을 내부적으로 실제 제공자 키와 매핑하는 방식으로, 클라이언트에게 실제 키를 노출하지 않고도 보안을 강화한다. 일반적인 OpenAI 호환 클라이언트나 개별 개발자에게 가장 깔끔한 해결책이며, 모델 라우터와 완벽하게 호환되어 CISO의 보안 요구사항을 충족한다.

근거

가상 API 키(Virtual API Key)는 모델 라우터와 함께 작동하며 보안성을 높인다. — Auth Method 2: Virtual API Key 섹션

OAuth Client Credentials 방식은 백엔드 서비스나 봇과 같은 애플리케이션 정체성을 기반으로 짧은 수명의 액세스 토큰을 발행하여 인증한다. 관리자가 등록한 클라이언트 ID와 비밀번호를 통해 토큰을 교환하며, 제어 가능한 코드 환경에서 운영되는 프로덕션 앱이나 예약된 작업에 최적화된 보안을 제공한다.

User OAuth 및 Identity Provider JWKS 방식은 사용자 개별 신원이나 기업의 기존 SSO 체계를 LLM 접근 제어에 직접 연동한다. User OAuth는 로그인한 사용자의 권한을 앱이 상속받도록 하며, JWKS는 Okta나 Microsoft Entra ID 등 IdP가 발행한 JWT를 직접 검증하여 기업 표준 보안 정책을 LLM 트래픽에 적용한다.

근거

JWKS 인증은 Okta, Auth0, Microsoft Entra ID 등 기존 기업 IdP와 연동 가능하다. — Auth Method 5: Identity Provider JWKS 섹션

기술

Archestra
OpenAI API
OAuth 2.1
JWKS
PKCE
Okta
Auth0
Microsoft Entra ID

활용 사례

기업 내 LLM 트래픽 통합 관리
멀티 테넌트 LLM 서비스 구축
기존 SSO 체계와 LLM 접근 제어 통합

언급된 리소스

문서LLM Proxy Authentication docs