line·2026년 4월 30일원문

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를 통해 인가 정책을 중앙화하고 보안 표준을 프로토콜 기반의 동적 신뢰 구조로 전환하는 전략적 검토가 권장됩니다.

sso데이터베이스 설계oauthjwt+4

figma·2019년 8월 26일·3분 읽기큐레이션 요약

Figma 데이터의 안전한 보호 및

Figma는 고객의 디자인 데이터와 지식재산을 보호하기 위해 보안을 제품 개발과 인프라 운영 전반의 핵심 원칙으로 삼고 있다. SOC 2 인증, 유럽 데이터 보호 체계, 플러그인 권한 제한, SAML 기반 SSO 등을 통해 규정 준수와 실제 서비스 보안을 함께 강화했다. 이후 업데이트에서는 SOC 2 Type 2와 SOC 3 보고서까지 취득해 내부 통제가 일정 기간 안정적으로 작동했음을 입증했다. ## SOC 2 인증으로 검증한 보안 통제 - SOC 2는 클라우드에 저장된 고객 데이터를 보호하기 위한 미국 소프트웨어 기업의 대표적인 보안 준수 기준이다. - 인증 과정에서 인프라, 소프트웨어, 인사 절차, 고객 데이터 처리 정책과 통제를 종합적으로 감사한다. - SOC 2 Type 1은 특정 시점에 통제가 마련되어 있는지를 확인하는 일종의 스냅샷이다. - SOC 2 Type 2는 통제가 일정 기간 실제로 작동했는지까지 검증하므로 더 높은 수준의 보증을 제공한다. - Figma는 글 작성 당시 Type 1 인증을 완료하고 Type 2를 추진 중이었으며, 2020년 업데이트에서 SOC 2 Type 2와 SOC 3 보고서 취득을 발표했다. ## 유럽 고객을 위한 데이터 보호와 준수 - 유럽 고객 증가에 맞춰 EU와 국제적인 데이터 보호 및 보안 요구사항을 충족하는 것을 목표로 했다. - EU-US Privacy Shield와 Swiss-US Privacy Shield 프레임워크 인증을 취득했다. - 이를 통해 유럽 및 스위스 고객이 Figma에 디자인 데이터를 저장할 때 필요한 개인정보 보호 체계를 마련했다고 설명한다. ## 기능 개발 단계부터 적용한 보안 원칙 - 보안은 별도의 사후 검토가 아니라 새로운 기능을 설계하고 개발하는 단계부터 고려하는 원칙으로 제시된다. - 특히 Figma Plugins처럼 외부 개발자가 플랫폼을 확장하는 기능은 보안·안정성·성능 사이의 균형이 중요했다. - 플러그인은 한 번에 하나의 디자인 파일에만 접근할 수 있다. - 플러그인이 사용자의 전체 계정이나 다른 플러그인의 데이터에 접근할 수 없도록 격리했다. - 플러그인이 Figma UI를 변경하지 못하게 해 사용자를 속이거나 피싱으로 유도할 가능성을 줄였다. - 일부 기능과 확장성을 제한하더라도 고객 데이터 보호를 우선한 설계 결정이었다. ## SAML SSO를 통한 기업 계정 관리 - 기업 고객을 위해 SAML 기반 싱글 사인온(SSO)을 지원했다. - SSO는 로그인 절차를 단순화하는 동시에 조직 전체에 Figma를 배포하고 사용자 접근 권한을 중앙에서 관리할 수 있게 한다. - 기존 Okta와 Microsoft Azure Active Directory에 더해 OneLogin도 통합 대상으로 추가했다. - 기업은 기존 인증·접근 관리 체계와 Figma를 연결해 퇴사자 계정 차단이나 사용자 권한 관리 등을 일관되게 운영할 수 있다. ## 실용적인 시사점 Figma의 사례는 SaaS 보안에서 인증서 취득만으로 끝나는 것이 아니라, 장기간 작동하는 내부 통제와 기능별 권한 격리, 기업용 접근 관리까지 함께 구축해야 한다는 점을 보여준다. 특히 플러그인이나 확장 기능을 도입할 때는 가능한 기능을 늘리는 것보다 데이터 접근 범위를 최소화하고 사용자 신뢰를 보호하는 설계가 우선되어야 한다.

원문 읽기(새 탭에서 열림)

sso클라우드 보안samlsecurity-compliance+2