Microsoft ID 플랫폼의 권한 및 동의 개요
이메일이나 일정 데이터와 같은 보호된 리소스에 액세스하려면 애플리케이션에 리소스 소유자의 권한 부여가 필요합니다. 리소스 소유자는 앱의 요청에 동의하거나 거부할 수 있습니다. 이러한 기본 개념을 이해하면 필요한 경우 사용자와 관리자에게 필요한 액세스만 요청하는 보다 안전하고 신뢰할 수 있는 애플리케이션을 빌드할 수 있습니다.
액세스 시나리오
애플리케이션 개발자는 애플리케이션이 데이터에 액세스하는 방법을 식별해야 합니다. 애플리케이션은 로그인한 사용자를 대신하여 작동하는 위임된 액세스를 사용하거나 애플리케이션 자체 ID로만 작동하는 앱 전용 액세스를 사용할 수 있습니다.
위임된 액세스(사용자를 대신하여 액세스)
이 액세스 시나리오에서 사용자는 클라이언트 애플리케이션에 로그인했습니다. 클라이언트 애플리케이션은 사용자를 대신하여 리소스에 액세스합니다. 위임된 액세스에는 위임된 권한이 필요합니다. 요청을 하려면 클라이언트와 사용자 모두 별도로 권한을 부여받아야 합니다. 위임된 액세스 시나리오에 대한 자세한 내용은 위임된 액세스 시나리오를 참조하세요.
클라이언트 앱의 경우 올바른 위임된 권한이 부여되어야 합니다. 위임된 권한은 범위라고도 합니다. 범위는 클라이언트 애플리케이션이 사용자를 대신하여 액세스할 수 있는 항목을 나타내는 지정된 리소스에 대한 권한입니다. 범위에 대한 자세한 내용은 범위 및 권한을 참조하세요.
사용자의 경우 권한 부여는 리소스에 액세스하기 위해 사용자에게 부여된 권한에 의존합니다. 예를 들어 사용자에게는 Microsoft Entra RBAC(역할 기반 액세스 제어)를 통해 디렉터리 리소스에 액세스하거나 Exchange Online RBAC를 통해 메일 및 일정 리소스에 액세스할 권한이 있습니다. 애플리케이션용 RBAC에 대한 자세한 내용은 애플리케이션용 RBAC를 참조하세요.
앱 전용 액세스(사용자 없는 액세스)
이 액세스 시나리오에서 애플리케이션은 로그인한 사용자 없이 자체적으로 작동합니다. 애플리케이션 액세스는 자동화 및 백업과 같은 시나리오에서 사용됩니다. 이 시나리오에는 백그라운드 서비스 또는 디먼으로 실행되는 앱이 포함됩니다. 특정 사용자가 로그인하는 것이 바람직하지 않거나 필요한 데이터의 범위를 단일 사용자로 지정할 수 없는 경우에 적합합니다. 앱 전용 액세스 시나리오에 대한 자세한 내용은 앱 전용 액세스를 참조하세요.
앱 전용 액세스는 위임된 범위 대신 앱 역할을 사용합니다. 동의를 통해 부여되는 경우 앱 역할을 애플리케이션 권한이라고도 합니다. 호출하는 리소스 앱의 적절한 애플리케이션 권한을 클라이언트 앱에 부여해야 합니다. 일단 부여되면 클라이언트 앱은 요청된 데이터에 액세스할 수 있습니다. 클라이언트 애플리케이션에 앱 역할을 할당하는 방법에 대한 자세한 내용은 애플리케이션에 앱 역할 할당을 참조하세요.
권한 형식
위임된 권한은 위임된 액세스 시나리오에서 사용됩니다. 애플리케이션이 사용자를 대신할 수 있도록 허용하는 권한입니다. 애플리케이션은 로그인한 사용자가 액세스할 수 없는 항목에는 절대 액세스할 수 없습니다.
예를 들어 사용자를 대신하여 Files.Read.All 위임된 권한이 부여된 애플리케이션을 사용합니다. 애플리케이션은 사용자가 개인적으로 액세스할 수 있는 파일만 읽을 수 있습니다.
앱 역할이라고도 하는 애플리케이션 권한은 로그인한 사용자가 없는 앱 전용 액세스 시나리오에서 사용됩니다. 애플리케이션은 권한과 관련된 모든 데이터에 액세스할 수 있습니다.
예를 들어 Microsoft Graph API의 애플리케이션 권한 Files.Read.All이 부여된 애플리케이션은 Microsoft Graph를 사용하여 테넌트의 모든 파일을 읽을 수 있습니다. 일반적으로 API 서비스 주체의 관리자 또는 소유자만 해당 API에서 노출하는 애플리케이션 권한에 동의할 수 있습니다.
위임된 권한과 애플리케이션 권한 비교
| 권한 유형 | 위임된 권한 | 애플리케이션 권한 |
|---|---|---|
| 앱의 유형 | 웹/모바일/SPA(단일 페이지 앱) | 웹/디먼 |
| 액세스 컨텍스트 | 사용자를 대신하여 액세스 권한 얻기 | 사용자 없이 액세스 권한 얻기 |
| 동의할 수 있는 사람 | - 사용자가 자신의 데이터에 동의할 수 있음 - 관리자는 모든 사용자에 대해 동의할 수 있음 |
관리자만 동의할 수 있음 |
| 동의 방법 | - 정적: 앱 등록에 구성된 목록 - 동적: 로그인 시 개별 권한 요청 |
- 정적 전용: 앱 등록에 구성된 목록 |
| 기타 이름 | - 범위 - OAuth2 권한 범위 |
- 앱 역할 - 앱 전용 권한 |
| 동의 결과(Microsoft Graph에만 해당) | OAuth2PermissionGrant | appRoleAssignment |
동의
애플리케이션에 권한이 부여되는 한 가지 방법은 동의를 통한 것입니다. 동의는 사용자 또는 관리자가 애플리케이션이 보호된 리소스에 액세스하도록 승인하는 프로세스입니다. 예를 들어 사용자가 애플리케이션에 처음 로그인하려고 하면 애플리케이션에서 사용자 프로필을 보고 사용자 사서함의 내용을 읽을 수 있는 권한을 요청할 수 있습니다. 사용자는 동의 확인 프롬프트를 통해 앱이 요청하는 권한 목록을 볼 수 있습니다. 사용자에게 동의 확인 프롬프트가 표시될 수 있는 다른 시나리오는 다음과 같습니다.
- 이전에 동의를 철회한 경우.
- 로그인 시 동의를 구체적으로 요청하도록 애플리케이션을 코딩한 경우.
- 애플리케이션이 동적 동의를 사용하여 런타임 시 필요에 따라 새 권한을 요청하는 경우.
동의 확인 프롬프트의 주요 세부 정보는 애플리케이션에 필요한 권한 목록과 게시자 정보입니다. 관리자와 최종 사용자 모두에 대한 동의 확인 프롬프트 및 동의 환경에 대한 자세한 내용은 애플리케이션 동의 환경을 참조하세요.
사용자 승인
사용자 동의는 사용자가 애플리케이션에 로그인을 시도할 때 발생합니다. 사용자가 로그인 자격 증명을 제공하여 동의가 이미 부여되었는지 확인합니다. 필요한 권한에 대한 사용자 또는 관리자 동의에 대한 이전 기록이 없는 경우 사용자에게 동의 확인 프롬프트가 표시되고 애플리케이션에 요청된 권한을 부여하라는 메시지가 표시됩니다. 관리자가 사용자를 대신하여 동의를 부여해야 할 수 있습니다.
관리자 동의
필요한 권한에 따라 일부 애플리케이션에서 관리자가 동의를 허용해야 할 수 있습니다. 예를 들어, 애플리케이션 권한과 많은 높은 권한이 위임된 권한은 관리자만 동의할 수 있습니다.
관리자는 자신 또는 전체 조직에 대해 동의를 부여할 수 있습니다. 사용자 및 관리자 동의에 대한 자세한 내용은 사용자 및 관리자 동의 개요를 참조하세요.
동의가 부여되지 않은 경우 및 해당 높은 권한 중 하나가 요청된 경우 관리자 동의를 요청하는 인증 요청이 표시됩니다.
사용자 지정 애플리케이션 범위를 포함하는 권한 요청은 높은 권한으로 간주되지 않으므로 관리자 동의가 필요하지 않습니다.
사전 권한 부여
사전 권한 부여를 통해 리소스 애플리케이션 소유자는 사전에 권한 부여된 동일한 권한 집합에 대한 동의 확인 프롬프트를 사용자에게 표시하지 않고도 권한을 부여할 수 있습니다. 이렇게 하면 사전에 권한 부여된 애플리케이션이 사용자에게 권한 동의를 요청하지 않습니다. 리소스 소유자는 Azure Portal에서 또는 Microsoft Graph와 같은 PowerShell 및 API를 사용하여 클라이언트 앱을 사전에 권한 부여할 수 있습니다.
기타 권한 부여 시스템
동의 프레임워크는 애플리케이션 또는 사용자가 보호된 리소스에 액세스할 수 있는 권한을 부여할 수 있는 한 가지 방법일 뿐입니다. 관리자는 중요한 정보에 대한 액세스 권한을 부여할 수 있는 다른 권한 부여 시스템을 알고 있어야 합니다. Microsoft의 다양한 권한 부여 시스템의 예로는 Entra 기본 제공 역할, Azure RBAC, Exchange RBAC 및 Teams 리소스별 동의가 있습니다.