애플리케이션 전용 액세스 이해

애플리케이션이 Microsoft Graph와 같은 리소스에 직접 액세스하는 경우 해당 액세스는 단일 사용자가 사용할 수 있는 파일이나 작업으로 제한되지 않습니다. 앱은 자체 ID를 사용하여 API를 직접 호출하며 관리자 권한이 있는 사용자 또는 앱은 리소스에 액세스할 수 있는 권한을 부여해야 합니다. 이 시나리오는 애플리케이션 전용 액세스입니다.

애플리케이션 전용 액세스는 언제 사용해야 하나요?

대부분의 경우 애플리케이션 전용 액세스는 위임된 액세스보다 광범위하고 강력하므로 필요한 경우에만 앱 전용 액세스를 사용해야 합니다. 일반적으로 다음과 같은 경우 올바른 선택입니다.

  • 애플리케이션은 사용자 입력 없이 자동화된 방식으로 실행되어야 합니다. 예를 들어, 특정 연락처의 이메일을 확인하고 자동 응답을 보내는 일별 스크립트입니다.
  • 애플리케이션은 여러 다른 사용자에게 속한 리소스에 액세스해야 합니다. 예를 들어, 백업 또는 데이터 손실 방지 앱은 각각 참가자가 다른 여러 채팅 채널에서 메시지를 검색해야 할 수 있습니다.
  • 자격 증명을 로컬에 저장하고 앱이 사용자 또는 관리자 "로" 로그인하도록 허용하고 싶은 유혹을 느낍니다.

반대로 사용자가 일반적으로 자신의 리소스를 관리하기 위해 로그인하는 애플리케이션 전용 액세스를 사용해서는 안 됩니다. 이러한 형식의 시나리오는 위임된 액세스를 사용하여 최소 권한을 받아야 합니다.

Diagram shows illustration of application permissions vs delegated permissions.

애플리케이션 전용 호출을 수행하도록 앱 권한 부여

앱 전용 호출을 하려면 클라이언트 앱에 적절한 앱 역할을 할당해야 합니다. 앱 역할은 애플리케이션 전용 권한이라고도 합니다. 역할을 정의하는 리소스 앱의 컨텍스트에서만 액세스 권한을 부여하므로 역할입니다.

예를 들어, 조직에서 만들어진 모든 팀 목록을 읽으려면 애플리케이션에 Microsoft Graph Team.ReadBasic.All 앱 역할을 할당해야 합니다. 이 앱 역할은 Microsoft Graph가 리소스 앱일 때 이 데이터를 읽을 수 있는 기능을 부여합니다. 이 할당은 클라이언트 애플리케이션을 다른 서비스를 통해 이 데이터를 볼 수 있도록 허용할 수 있는 Teams 역할에 할당하지 않습니다.

개발자는 애플리케이션 등록에서 앱 역할이라고도 하는 모든 필수 앱 전용 권한을 구성해야 합니다. Azure Portal 또는 Microsoft Graph를 통해 앱의 요청된 앱 전용 권한을 구성할 수 있습니다. 앱 전용 액세스는 동적 동의를 지원하지 않으므로 런타임 시 개별 권한 또는 권한 집합을 요청할 수 없습니다.

앱에 필요한 모든 권한을 구성한 후 리소스에 액세스하려면 관리자 동의가 필요합니다. 예를 들어, 전역 관리자 역할이 있는 사용자만 Microsoft Graph API에 대한 앱 전용 권한(앱 역할)을 부여할 수 있습니다. 애플리케이션 관리자 및 클라우드 앱 관리자와 같은 다른 관리자 역할을 가진 사용자는 다른 리소스에 대한 앱 전용 권한을 부여할 수 있습니다.

관리 사용자는 Azure Portal을 사용하거나 Microsoft Graph API를 통해 프로그래밍 방식으로 부여를 만들어 앱 전용 권한을 부여할 수 있습니다. 앱 내에서 대화형 동의를 요청할 수도 있지만 앱 전용 액세스에는 사용자가 필요하지 않으므로 이 옵션은 바람직하지 않습니다.

Outlook.com 또는 Xbox Live 계정과 같은 Microsoft 계정이 있는 소비자 사용자는 애플리케이션 전용 액세스를 권한 부여할 수 없습니다. 항상 최소 권한 원칙을 따릅니다. 앱에 필요하지 않은 앱 역할을 요청해서는 안 됩니다. 이 원칙은 앱이 손상된 경우 보안 위험을 제한하고 관리자가 앱 액세스 권한을 더 쉽게 부여할 수 있도록 합니다. 예를 들어, 앱 전용에서 자세한 프로필 정보를 읽지 않고 사용자를 식별해야 하는 경우 User.Read.All 대신 더 제한된 Microsoft Graph User.ReadBasic.All 앱 역할을 요청해야 합니다.

리소스 서비스에 대한 앱 역할 디자인 및 게시

다른 클라이언트가 호출할 API를 노출하는 Microsoft Entra ID에서 서비스를 빌드하는 경우 앱 역할(앱 전용 권한)로 자동화된 액세스를 지원하고자 할 수 있습니다. Microsoft Entra 관리 센터에서 앱 등록의 앱 역할 섹션에서 애플리케이션에 대한 앱 역할을 정의할 수 있습니다. 앱 역할을 만드는 방법에 대한 자세한 내용은 애플리케이션의 역할 선언을 참조하세요.

다른 사람이 사용할 앱 역할을 노출할 때 역할을 할당할 관리자에게 시나리오에 대한 명확한 설명을 제공합니다. 앱 전용 액세스는 사용자 권한에 의해 제한되지 않으므로 앱 역할은 일반적으로 가능한 한 좁고 특정 기능 시나리오를 지원해야 합니다. 서비스에 포함된 모든 API 및 리소스에 대한 전체 read 또는 전체 read/write 액세스 권한을 부여하는 단일 역할을 노출하지 마세요.

참고 항목

사용자 및 그룹에 대한 할당을 지원하도록 앱 역할(앱 전용 권한)을 구성할 수도 있습니다. 의도한 액세스 시나리오에 대해 앱 역할을 올바르게 구성했는지 확인합니다. API의 앱 역할을 앱 전용 액세스에 사용하려는 경우 앱 역할을 만들 때 허용되는 유일한 멤버 형식으로 애플리케이션을 선택합니다.

애플리케이션 전용 액세스는 어떻게 작동하나요?

앱 전용 액세스에 대해 기억해야 할 가장 중요한 점은 호출하는 앱이 자신을 대신하여 자신의 ID로 작동한다는 것입니다. 사용자 상호 작용이 없습니다. 앱이 리소스에 대해 할당된 앱 역할에 할당된 경우 앱은 해당 앱 역할이 관리하는 모든 리소스 및 작업에 대해 완전히 무제한 액세스할 수 있습니다.

앱이 하나 이상의 앱 역할(앱 전용 권한)에 할당되면 클라이언트 자격 증명 흐름 또는 기타 지원되는 인증 흐름을 사용하여 Microsoft Entra ID에서 앱 전용 토큰을 요청할 수 있습니다. 할당된 역할은 앱 액세스 토큰의 roles 클레임에 추가됩니다.

일부 시나리오에서 애플리케이션 ID는 위임된 호출의 사용자 권한과 유사하게 액세스 권한 부여 여부를 결정할 수 있습니다. 예를 들어, Application.ReadWrite.OwnedBy 앱 역할은 앱이 소유한 서비스 주체를 관리할 수 있는 기능을 앱에 부여합니다.

애플리케이션 전용 액세스 예 - Microsoft Graph를 통한 자동화된 이메일 알림

다음 예에서는 현실적인 자동화 시나리오를 보여 줍니다.

Alice는 Windows 파일 공유에 있는 부서 보고 폴더가 새 문서를 등록할 때마다 이메일로 팀에 알리려고 합니다. Alice는 폴더를 검사하고 새 파일을 찾기 위해 PowerShell 스크립트를 실행하는 예약된 작업을 만듭니다. 그런 다음 스크립트는 리소스 API인 Microsoft Graph로 보호되는 사서함을 사용하여 이메일을 보냅니다.

스크립트는 사용자 상호 작용 없이 실행되므로 권한 부여 시스템은 애플리케이션 권한 부여만 확인합니다. Exchange Online은 전화를 거는 클라이언트가 관리자로부터 애플리케이션 권한(앱 역할) Mail.Send를 부여받았는지 확인합니다. 앱에 Mail.Send가 부여되지 않으면 Exchange Online이 요청에 실패합니다.

POST /users/{id}/{userPrincipalName}/sendMail Mail.Send가 부여된 클라이언트 앱 클라이언트 앱에 Mail.Send가 부여되지 않았습니다.
스크립트는 Alice의 사서함을 사용하여 이메일을 보냅니다. 200 – 액세스 권한 부여됨 관리자는 앱이 모든 사용자로 메일을 보낼 수 있도록 허용했습니다. 403 - 권한 없음 관리자가 이 고객에게 이메일을 보내도록 허용하지 않았습니다.
스크립트는 이메일을 보낼 전용 사서함을 만듭니다. 200 – 액세스 권한 부여됨 관리자는 앱이 모든 사용자로 메일을 보낼 수 있도록 허용했습니다. 403 - 권한 없음 관리자가 이 고객에게 이메일을 보내도록 허용하지 않았습니다.

지정된 예는 애플리케이션 권한 부여에 대한 간단한 설명입니다. 프로덕션 Exchange Online 서비스는 특정 Exchange Online 사서함에 대한 애플리케이션 권한 제한과 같은 다른 많은 액세스 시나리오를 지원합니다.

다음 단계