Microsoft ID 동의 프레임워크로 보호되는 API의 예

이 문서는 개발자가 최소 권한을 제공하도록 애플리케이션 사용 권한 전략을 설계하는 데 도움이 될 수 있습니다. 계속하기 전에 등록, 권한 및 액세스에 대한 모범 사례를 알아보려면 API 보호 문서를 참조하세요.

Microsoft ID 플랫폼으로 보호되는 API가 Microsoft ID 동의 프레임워크를 사용하는 방법을 살펴보겠습니다. Microsoft ID 플랫폼 동의 프레임워크를 가장 광범위하게 사용하기 때문에 Microsoft Graph API를 예제로 사용합니다.

사용 권한 이름에 대한 명명 규칙

Microsoft Graph 팀은 사용 권한 이름에 대한 명명 규칙을 만들어 사용 권한을 활성화하는 리소스 액세스에 더 쉽게 연결할 수 있도록 했습니다. Microsoft Graph 권한 이름은 간단한 resource.operation.constraint 패턴을 준수합니다. 두 가지 기본 작업은 Read 및 ReadWrite (업데이트 및 삭제 포함)입니다.

제약 조건 요소는 앱이 디렉터리 내에 있는 액세스 정도에 영향을 줍니다. Microsoft Graph는 다음과 같은 제약 조건을 지원합니다.

• 모든 권한은 앱이 디렉터리에서 지정된 형식의 모든 리소스에 대한 작업을 수행할 수 있는 권한을 부여합니다.
• 공유는 로그인한 사용자와 다른 사용자가 공유한 리소스에 대한 작업을 앱이 수행할 수 있도록 권한을 부여합니다.
• AppFolder 는 OneDrive의 전용 폴더에 있는 파일을 읽고 쓸 수 있는 권한을 앱에 부여합니다. 이 제약 조건은 Files 권한 개체에만 노출되며 Microsoft 계정에만 유효합니다.
• 제약 조건 없음을 지정하는 경우 앱은 로그인한 사용자가 소유한 리소스에 대해서만 작업을 수행할 수 있습니다.

특정 리소스에 대한 액세스 및 작업

Microsoft Graph의 사용자 개체에 대한 일부 사용 권한 또는 범위를 살펴보고 Microsoft API 디자이너가 특정 리소스에 대해 특정 액세스 및 작업을 사용하도록 설정한 방법을 살펴보겠습니다.

애플리케이션이 최소 권한의 제로 트러스트 원칙을 따를 수 있도록, User.Read와 User.ReadWrite은 각각 존재하며, 이는 User.Access처럼 존재하지 않는 단일 권한과는 대조적입니다. 개발자가 사용자의 프로필을 업데이트하기 위한 요구 사항 및 코드가 없는 경우 앱은 요청 User.ReadWrite하지 않습니다. 따라서 잘못된 행위자가 애플리케이션을 손상시키고 데이터를 변경하는 데 사용할 수 없습니다.

애플리케이션에 User.Read 사용자 개체에 대한 액세스 권한만 부여하는 것은 아닙니다. 각 권한은 특정 작업 범위를 나타냅니다. 개발자와 관리자는 사용 권한 설명을 읽어 특정 사용 권한이 사용하도록 설정하는 항목을 정확하게 확인하는 것이 중요합니다. User.Read현재 사용자의 전체 프로필을 읽을 수 있도록 설정하는 것 외에도 애플리케이션은 Microsoft Graph의 Organizations 개체에서 기본 정보를 볼 수 있습니다.

다른 사용 권한을 살펴보겠습니다.

User.Read의 모든 작업으로 시작하는 User.ReadBasic.All의 작동 범위입니다. 또한 다른 조직 사용자의 표시 이름, 이름과 성, 전자 메일 주소, 사진 및 열린 확장 기능에 액세스할 수 있습니다. 특정 작업 범위를 사용하면 애플리케이션에서 좋은 사용자 선택기 UI를 가질 수 있으며, 특정 범위의 작업을 사용하도록 설정하는 권한을 사용하는 API 디자이너의 예입니다.

Microsoft Graph 사용자 개체에 대한 몇 가지 권한을 더 살펴보겠습니다.

User.Read 및 User.ReadWrite와 마찬가지로, User.Read.All 및 User.ReadWrite.All는 애플리케이션이 최소 권한 제로 트러스트 원칙을 따를 수 있도록 하는 별개의 권한입니다.

User.Read.All 조직의 모든 사용자에게 이 기능이 있기 때문에 흥미롭습니다(예: Outlook 열기, 보고 체인 위아래로 이동). 개인은 조직의 다른 모든 사용자의 전체 사용자 프로필을 볼 수 있습니다. 그러나 Microsoft Graph API 디자이너는 테넌트의 조직 계층 구조를 포함하기 때문에 User.Read.All 관리자만 애플리케이션이 동일한 작업을 수행하도록 허용해야 한다고 결정했습니다. 악의적인 행위자가 이 정보에 액세스하면 사용자의 관리자 또는 관리자 상급자를 가장하여 피싱 이메일을 보내는 대상 피싱 공격을 실시할 수 있습니다.

User.ReadWrite.All 는 강력한 작업 범위입니다. 이 권한이 있는 애플리케이션은 테넌트에 있는 모든 사용자를 업데이트하거나 삭제할 수 있습니다. 위임된 권한으로 사용자가 앱 앞에 있을 때 앱은 현재 사용자가 수행할 수 있는 작업만 수행할 수 있습니다. 일반 사용자는 앱의 사용 권한에 관계없이 다른 사용자를 업데이트하거나 삭제할 수 없습니다. 그러나 테넌트 관리자가 앱을 사용하는 경우 이러한 작업을 수행할 수 있습니다. 이 권한을 부여하거나 거부하기로 결정한 경우 테넌트 관리자 사용자를 염두에 두고 앱을 평가합니다.

관리자 동의가 필요한 권한

User.Read.All 및 User.ReadWrite.All의 강력한 기능 때문에, Microsoft Graph API 디자이너는 이러한 사용 권한을 관리자 동의를 요구하는 권한으로 지정했습니다. 사용 권한 테이블에 관리자? 열을 추가하여 사용 권한에 관리자 동의가 필요한 시기를 표시해 보겠습니다.

관리 동의 문서가 필요한 요청 권한에 설명된 것처럼 테넌트 관리자는 요구 사항을 재정의하고 테넌트에서 모든 애플리케이션 권한을 관리자 동의가 필요한 것으로 지정할 수 있습니다. 요청에서 토큰을 받지 못할 때 정상적으로 처리하도록 앱을 디자인합니다. 동의가 부족한 것은 앱이 토큰을 받지 못할 수 있는 여러 가지 이유 중 하나입니다.

다음 단계

• API 간 호출은 한 API가 다른 API를 호출해야 할 때, 그리고 응용 프로그램이 사용자를 대신하여 작동할 때, 제로 트러스트를 보장하고 애플리케이션을 안전하게 개발하는 데 도움이 됩니다.
• 리소스에 액세스하기 위한 권한 부여를 획득 하면 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트를 가장 잘 보장하는 방법을 이해하는 데 도움이 됩니다.
• 토큰 사용자 지정은 Microsoft Entra 토큰에서 받을 수 있는 정보를 설명합니다. 최소 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 향상시키기 위해 토큰을 사용자 지정하는 방법을 설명합니다.
• 토큰에서 그룹 클레임 및 앱 역할을 구성 하면 앱 역할 정의를 사용하여 앱을 구성하고 앱 역할에 보안 그룹을 할당하는 방법을 보여 줍니다. 이러한 방법은 최소한의 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 개선하는 데 도움이 됩니다.
• 관리자 동의가 필요한 요청 권한은 애플리케이션 권한이 관리자 동의를 필요로 할 때의 사용 권한 및 동의 경험을 설명합니다.
• 이 빠른 시작: Microsoft ID 플랫폼을 사용하여 웹 API를 보호하고, ASP.NET Web API를 보호하는 방법을 보여 주는 코드 샘플을 다운로드하여 실행합니다.
• 이 자습서 - Azure API Management에서 API 변환 및 보호, API HTTP 응답 본문에서 기술 스택 정보 및 원래 URL을 숨기도록 일반적인 정책을 구성하는 방법에 대해 알아봅니다.
• 권한 부여 모범 사례는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.