jwt

AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG (새 탭에서 열림)

AI 에이전트가 다양한 기업용 서비스와 연동되는 과정에서 발생하는 인증 및 인가 복잡성을 해결하기 위해 **Identity Assertion JWT Authorization Grant(ID-JAG)**라는 새로운 표준안이 주목받고 있습니다. ID-JAG는 기존 SSO의 신뢰 모델을 API 접근 영역으로 확장하여, 기업 IdP가 중앙에서 권한 정책을 일원화해 관리하고 검증 가능한 JWT를 통해 안전하게 토큰을 교환하도록 돕습니다. 이를 통해 사용자 경험을 개선하고 보안 가시성을 확보함으로써, 복잡한 연동 구조가 AI 도입의 병목이 되지 않도록 하는 것이 핵심입니다. **ID-JAG의 개념과 기술적 배경** * SSO를 통해 확립된 IdP(Identity Provider)에 대한 신뢰를 앱 간 API 호출이나 에이전트 서비스 연동에 적용하는 방식입니다. * OAuth 2.0 Token Exchange(RFC 8693)와 JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523)라는 기존의 두 표준 기술을 결합하여 작동합니다. * IdP가 서명한 검증 가능한 JWT를 일종의 '소개장'으로 발행하고, API 리소스 측 인가 서버가 이 소개장을 신뢰하여 최종 액세스 토큰을 발행하는 구조입니다. **핵심 구성 요소와 작동 흐름** * **주요 주체:** 요청 에이전트(AI 등), 기업 IdP(중앙 정책 보유), 인가 서버(대상 앱의 서버), 리소스 서버(실제 API)의 네 가지 역할로 구분됩니다. * **작동 프로세스:** 사용자가 에이전트에 로그인하여 ID 토큰 획득 → IdP에 토큰 교환을 요청하여 ID-JAG 발급 → 인가 서버에 ID-JAG를 제시하고 최종 액세스 토큰 획득 → 리소스 서버 API 호출 순으로 진행됩니다. * **권한 판단의 주체 변화:** 개별 서비스 간의 파편화된 관계 대신, 조직 전체를 관리하는 기업 IdP와 인가 서버 간의 신뢰 관계로 허가 판단 시점이 이동합니다. **조직의 운영 및 보안 측면의 이점** * **사용자 경험(UX) 개선:** 새로운 도구를 연동할 때마다 나타나는 권한 동의 화면(Consent Screen) 절차를 IdP 관리자 정책에 통합하여 사용자의 번거로움을 줄입니다. * **보안 가시성 확보:** 모든 서비스 연결 관계가 IdP로 집중되므로, 누가 어떤 에이전트를 통해 어떤 데이터에 접근했는지 중앙 로그를 통해 명확하게 감사(Audit)할 수 있습니다. * **중앙 집중형 리스크 통제:** 승인되지 않은 '섀도우 AI'의 접근을 차단하고, 보안 사고 발생 시 개별 엔드포인트를 수정할 필요 없이 IdP 단에서 즉각적으로 권한을 제어할 수 있습니다. * **토큰 스프롤(Sprawl) 방지:** 장기 유효한 API 키나 리프레시 토큰 대신 동적으로 발행되는 ID-JAG를 사용하여 시스템 곳곳에 흩어진 인증 정보 노출 리스크를 낮춥니다. **도입 시 고려 사항 및 실용적 제언** * **표준화 상태 유의:** 현재 IETF 드래프트 단계이며 RFC로 최종 확정된 사양이 아니므로, 향후 변경 가능성을 염두에 둔 유연한 아키텍처 설계가 필요합니다. * **사전 신뢰 관계 구축:** 요청 에이전트가 IdP와 인가 서버 모두에 OAuth 클라이언트로 등록되어야 하며, 각 주체 간의 명시적인 신뢰 설정이 선행되어야 합니다. * **결론:** AI 에이전트 도입으로 인해 파편화된 권한 관리에 어려움을 겪는 기업이라면, ID-JAG를 통해 인가 정책을 중앙화하고 보안 표준을 프로토콜 기반의 동적 신뢰 구조로 전환하는 전략적 검토가 권장됩니다.

Access를 위한 관리형 OAuth: 클릭 한 번으로 내부 앱을 에이전트 대응 가능하게 만들기 (새 탭에서 열림)

Cloudflare는 내부 애플리케이션을 보호하는 'Cloudflare Access'에 클릭 한 번으로 활성화 가능한 'Managed OAuth' 기능을 도입하여 AI 에이전트의 접근성 문제를 해결했습니다. 기존에는 에이전트가 인증 페이지의 리다이렉션을 처리하지 못해 내부 데이터에 접근할 수 없었으나, 이제 OAuth 2.0 표준을 통해 에이전트가 사용자 대신 안전하게 인증을 수행하고 권한을 위임받을 수 있습니다. 이를 통해 기업은 수많은 레거시 앱의 코드를 수정하지 않고도 AI 에이전트가 즉시 활용할 수 있는 환경을 구축할 수 있게 되었습니다. **Managed OAuth의 작동 원리와 기술 표준** * Cloudflare Access가 직접 권한 부여 서버(Authorization Server) 역할을 수행하여 인증되지 않은 에이전트에게 `www-authenticate` 헤더를 반환합니다. * 에이전트는 RFC 9728 표준에 따라 `/.well-known/oauth-authorization-server` 경로에서 인증 서버 정보를 자동으로 탐색합니다. * RFC 7591(동적 클라이언트 등록)을 통해 에이전트가 자신을 클라이언트로 등록하고, RFC 7636(PKCE) 기반의 인증 흐름을 통해 보안성을 확보합니다. * 사용자가 인증을 승인하면 에이전트는 사용자 ID가 포함된 JWT(JSON Web Token)를 발급받아 이후 요청에 활용합니다. **레거시 앱의 즉각적인 AI 대응 환경 구축** * 수많은 내부 앱과 위키, REST API 등을 AI 에이전트가 읽을 수 있도록 개별적으로 코드를 수정하거나 별도의 MCP(Model Context Protocol) 서버를 구축할 필요가 없습니다. * Cloudflare Access 전면에 Managed OAuth를 활성화하는 것만으로 기존 앱들을 에이전트 친화적인 환경으로 즉시 업그레이드할 수 있습니다. * 특히 내부 위키와 같은 서비스의 경우 'Markdown for Agents' 기능과 Managed OAuth를 결합하여 에이전트가 보호된 콘텐츠를 원활하게 소비하도록 지원합니다. **서비스 계정 방식의 보안 한계 극복** * 정적 자격 증명을 사용하는 서비스 계정(Service Account) 방식은 감사 로그에서 실제 행위자를 파악하기 어렵고 '혼동된 대리인(Confused Deputy)' 문제에 취약합니다. * Managed OAuth는 모든 에이전트의 작업을 실제 사용자의 ID와 연결하므로, 사용자가 가진 권한 범위 내에서만 에이전트가 동작하도록 엄격히 제어합니다. * 이를 통해 기업은 보안 정책을 유지하면서도 어떤 사용자의 에이전트가 어떤 데이터에 접근했는지 명확한 감사 추적(Audit Log)을 남길 수 있습니다. **에이전트 도구의 표준 채택 권고** * 현재 대부분의 에이전트용 'web fetch' 도구는 HTTP 응답의 `www-authenticate` 헤더를 처리하지 못하는 한계가 있습니다. * Cloudflare는 에이전트가 MCP 서버뿐만 아니라 일반적인 웹 페이지나 API에 접근할 때도 RFC 9728 표준을 준수하여 자동으로 OAuth 흐름을 수행할 것을 제안합니다. * 이를 위해 오픈소스 프로젝트인 OpenCode의 web fetch 도구에 해당 표준을 적용하는 예시를 제시하며 에이전트 생태계의 표준화를 촉구하고 있습니다. 내부 인프라의 보안을 유지하면서 AI 에이전트의 활용도를 높이고 싶다면, 정적 토큰이나 서비스 계정 대신 Managed OAuth를 활성화하여 사용자 중심의 권한 위임 체계를 구축하는 것이 권장됩니다. 이는 보안 감사 가시성을 확보하는 동시에 가장 빠르고 효율적으로 내부 앱을 AI 시대에 맞게 현대화하는 방법입니다.

번호판에서 배지로: (새 탭에서 열림)

Cloudflare는 에이전트 설치가 불가능한 환경에서도 사용자 신원을 확인하고 보안 정책을 적용할 수 있는 'Gateway Authorization Proxy'를 출시했습니다. 기존의 IP 기반 필터링에서 벗어나 브라우저의 기본 프록시 기능과 Cloudflare Access를 결합함으로써, 관리되지 않는 기기에서도 사용자별로 세밀한 트래픽 제어와 가시성 확보가 가능해졌습니다. 이는 기업 인수합병(M&A), VDI 환경, 규제가 엄격한 산업군에서 보안 공백을 메우는 강력한 해결책이 될 것입니다. ### IP 기반 프록시의 한계와 정체성 위기 * 기존의 프록시 엔드포인트 방식은 정적 IP 주소에 의존하여 사용자를 식별했기 때문에, '누가' 접속하는지가 아닌 '어느 IP'에서 오는지만 인식할 수 있었습니다. * 사용자가 장소를 옮겨 IP가 변경되면 정책이 제대로 적용되지 않는 취약함이 있었으며, 보안 로그에는 사용자 이름 대신 익명 IP만 기록되는 문제가 있었습니다. * 또한 프록시 설정을 안내하는 PAC(Proxy Auto-Configuration) 파일을 기업이 직접 호스팅하고 수동으로 관리해야 하는 운영상의 번거로움이 존재했습니다. ### 신원 기반 인증 프록시의 작동 원리 * 새로운 방식은 차량 번호판(IP) 대신 개별 배지(ID)를 확인하는 것과 같으며, Cloudflare Access와 연동하여 사용자가 누구인지 먼저 검증한 뒤 Gateway 필터링 정책을 적용합니다. * 서명된 JWT(JSON Web Token) 쿠키를 사용하여 신원을 유지하며, 도메인별 보안 토큰을 생성하여 세션을 관리합니다. * 이 모든 인증 과정은 Cloudflare의 글로벌 에지 네트워크에서 수 밀리초 내에 처리되므로, 사용자는 리다이렉트 과정을 거의 느끼지 못한 채 평소처럼 웹 서핑을 할 수 있습니다. ### 다중 ID 공급자 지원 및 통합 관리 * Okta, Azure AD 등 여러 ID 공급자(IdP)를 동시에 지원하여, 서로 다른 인증 체계를 가진 기업들이 합병되는 과정에서도 유연하게 보안을 통합할 수 있습니다. * 클라이언트를 설치하지 않고도 "재무팀만 특정 회계 도구에 접속 가능"과 같은 정교한 사용자별 정책 수립이 가능합니다. * 사용자별 라이선스(Seat) 기반의 단순한 과금 체계를 적용하여 기존 Cloudflare One Client 사용자들과 동일한 방식으로 비용을 관리할 수 있습니다. ### PAC 파일 호스팅 자동화와 AI 지원 * 기업은 이제 PAC 파일을 직접 관리할 필요 없이 Cloudflare 네트워크에서 직접 호스팅하고 배포할 수 있습니다. * 다양한 설정 템플릿을 제공하여 수 분 내에 설정을 완료할 수 있으며, AI 어시스턴트 'Cloudy'가 복잡한 PAC 코드를 요약하고 설명해 주어 설정 오류를 방지합니다. ### 권장 활용 시나리오 Cloudflare는 최상의 사용자 경험을 위해 전용 클라이언트(Cloudflare One Client) 설치를 우선적으로 권장하지만, 다음과 같은 특수 상황에서는 Gateway Authorization Proxy가 최적의 대안이 됩니다. * **VDI(가상 데스크톱) 환경:** 사용자가 가상 머신에 로그인하여 브라우저를 통해서만 인터넷에 접속하는 경우 * **인수합병(M&A):** 서로 다른 보안 환경을 가진 두 회사를 신속하게 하나의 보안 체계로 통합해야 할 때 * **규제 준수 및 제한적 환경:** 보안 정책이나 법적 문제로 인해 엔드포인트 기기에 소프트웨어를 설치할 수 없는 경우