에이전트는 FIC(페더레이션 ID 자격 증명)에서 사용하도록 설정된 특수 토큰 교환 패턴이 있는 OAuth 2.0 프로토콜을 사용합니다. 모든 에이전트 인증 흐름에는 에이전트 ID 청사진이 에이전트 ID를 가장하여 작업을 수행하는 다단계 토큰 교환이 포함됩니다. 이 문서에서는 에이전트에서 사용하는 인증 프로토콜 및 토큰 흐름을 설명합니다. 위임 시나리오, 자율 작업 및 페더레이션 ID 자격 증명 패턴을 다룹니다. 이러한 프로토콜 단계를 구현하는 것은 쉽지 않으므로 에이전트 ID용 Microsoft Entra SDK와 같은 SDK 를 사용하는 것이 좋습니다.
모든 에이전트 개체는 기밀 클라이언트로, 대리 시나리오에 대한 API 역할을 할 수 있습니다. 대화형 흐름은 에이전트 엔터티 형식에 대해 지원되지 않으므로 모든 인증이 사용자 상호 작용 흐름이 아닌 프로그래밍 방식 토큰 교환을 통해 수행되도록 합니다.
경고
Microsoft에서는 Microsoft.Identity.Web 및 Microsoft 에이전트 ID SDK 라이브러리와 같은 승인된 SDK를 사용하여 이러한 프로토콜을 구현하는 것이 좋습니다. 이러한 프로토콜의 수동 구현은 복잡하고 오류가 발생하기 쉬 하며 SDK를 사용하면 보안 및 모범 사례를 준수하는 데 도움이 됩니다.
필수 조건
아직 익숙하지 않은 경우 다음 프로토콜 문서를 참조하세요.
- Microsoft ID 플랫폼 및 OAuth 2.0 온플로우Behalf-Of
- Microsoft ID 플랫폼 및 OAuth 2.0 클라이언트 자격 증명 흐름
지원되는 권한 부여 유형
다음은 에이전트 애플리케이션에 대해 지원되는 권한 부여 유형입니다.
에이전트 아이디 설계도
에이전트 신원 청사진은 가장하기 시나리오에 대한 보안 토큰 획득을 지원 client_credentials 합니다. 권한 부여 유형은 jwt-bearerOn-Behalf Of 시나리오에서 토큰 교환을 용이하게 하여 위임 패턴을 허용합니다.
refresh_token 권한 부여는 사용자 컨텍스트를 사용하여 백그라운드 작업을 수행할 수 있도록 하며, 사용자 권한을 유지하는 장기 실행 프로세스를 지원합니다.
에이전트 ID
에이전트 ID는 앱 전용 자율 작업에서 client_credentials를 사용하며, 사용자 컨텍스트 없이 독립적인 기능을 수행할 수 있도록 설정되고, 사용자 에이전트 ID로 가장합니다. 권한 부여 형식은 jwt-bearer 위임 패턴에서 유연성을 제공하는 클라이언트 자격 증명 흐름 과 OBO(On-Behalf Of) 흐름을 모두 지원합니다.
refresh_token 는 백그라운드 사용자 위임 작업을 용이하게 하여 에이전트 ID가 확장된 작업에서 사용자 컨텍스트를 유지할 수 있도록 합니다.
지원되지 않는 흐름
에이전트 애플리케이션 모델은 보안 경계를 유지하기 위해 특정 인증 패턴을 명시적으로 제외합니다. 엔드포인트를 사용하는 OBO 흐름은 어떤 에이전트 엔티티에도 지원되지 않으며, 이는 모든 인증이 프로그래밍 방식으로 수행되도록 하기 위함입니다.
공용 클라이언트 기능을 사용할 수 없으므로 모든 에이전트가 기밀 클라이언트로 작동해야 합니다. 리디렉션 URL은 지원되지 않습니다.
핵심 프로토콜 패턴
에이전트는 다음 세 가지 기본 모드에서 작동할 수 있습니다.
- Microsoft Entra ID(대화형 에이전트)에서 일반 사용자를 대신하여 작동하는 에이전트입니다. 이는 일반적인 대신 흐름입니다.
- 에이전트는 자율적으로 작동하며, 에이전트를 위해 만들어진 서비스 주체를 사용합니다.
- 사용자 주체를 특별히 해당 에이전트를 위해 생성하여 자체적으로 활동하는 에이전트(예: 자체 사서함이 있는 에이전트).
관리 ID 통합
관리 ID는 기본 자격 증명 유형입니다. 이 구성에서 관리 ID 토큰은 부모 에이전트 ID 청사진에 대한 자격 증명 역할을 하는 반면 표준 MSI 프로토콜은 자격 증명 획득에 적용됩니다. 이러한 통합을 통해 에이전트 ID는 자동 자격 증명 회전 및 보안 스토리지를 포함하여 MSI 보안 및 관리의 모든 이점을 받을 수 있습니다.
경고
클라이언트 비밀은 보안 위험으로 인해 에이전트 ID 청사진에 대한 프로덕션 환경에서 클라이언트 자격 증명으로 사용해서는 안 됩니다. 대신 관리 ID 또는 클라이언트 인증서와 함께 FIC(페더레이션 ID 자격 증명)와 같은 보다 안전한 인증 방법을 사용합니다. 이러한 메서드는 애플리케이션 구성 내에서 직접 중요한 비밀을 저장할 필요가 없도록 하여 향상된 보안을 제공합니다.
Oauth 프로토콜
세 가지 에이전트 OAuth 플로우가 있습니다.
- 흐름을 대신하는 에이전트: 일반 사용자(대화형 에이전트)를 대신하여 작동하는 에이전트입니다.
- 자율 앱 흐름: 앱 전용 작업을 사용하면 에이전트 ID가 사용자 컨텍스트 없이 자율적으로 작동할 수 있습니다.
- 에이전트 사용자 흐름: 에이전트를 위해 특별히 생성된 사용자 보안 주체를 사용하여 스스로 작동하는 에이전트입니다.