Microsoft Entra 로그인을 사용하도록 App Service 또는 Azure Functions 앱 구성
참고 항목
2024년 6월 1일부터 새로 만든 App Service 앱은 명명 규칙을 <app-name>-<random-hash>.<region>.azurewebsites.net사용하는 고유한 기본 호스트 이름을 생성할 수 있습니다. 기존 앱 이름은 변경되지 않은 상태로 유지됩니다. 예시:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
자세한 내용은 App Service 리소스에 대한 고유 기본 호스트 이름을 참조 하세요.
다른 인증 공급자를 선택하여 해당 공급자로 이동합니다.
이 문서에서는 앱이 인증 공급자로 Microsoft ID 플랫폼(Microsoft Entra)을 사용하여 사용자를 로그인하도록 Azure App Service 또는 Azure Functions에 대한 인증을 구성하는 방법을 보여 줍니다.
애플리케이션 및 애플리케이션 사용자 관련 테넌트 선택
애플리케이션에서 사용자를 로그인하려면 인력 또는 외부 테넌트에 등록해야 합니다. 직원 또는 비즈니스 게스트가 앱을 사용할 수 있도록 하는 경우 인력 테넌트에 앱을 등록합니다. 소비자 및 비즈니스 고객을 위한 앱인 경우 외부 테넌트에 등록합니다.
Azure Portal에 로그인하고 IoT Hub로 이동합니다.
앱의 왼쪽 메뉴에서 설정>인증을 선택한 다음 ID 공급자 추가를 선택합니다.
ID 공급자 추가 페이지에서 ID 공급자로 Microsoft를 선택하여 Microsoft 및 Microsoft Entra ID로 로그인합니다.
애플리케이션 및 해당 사용자에 대한 테넌트 선택에서 직원 및 비즈니스 게스트에 대한 Workforce 구성(현재 테넌트)을 선택하거나 소비자 및 비즈니스 고객을 위한 외부 구성을 선택합니다.
앱 등록 선택하기
App Service 인증 기능은 자동으로 앱 등록을 만들거나 사용자 또는 디렉터리 관리자가 별도로 만든 등록을 사용할 수 있습니다.
앱 등록을 별도로 만들 필요가 없는 경우라면 자동으로 새 앱 등록을 만듭니다. 원하는 경우 나중에 Microsoft Entra 관리 센터에서 앱 등록을 사용자 지정할 수 있습니다.
기존 앱 등록을 사용하는 가장 일반적인 경우는 다음과 같습니다.
- 계정에 Microsoft Entra 테넌트에서 앱 등록을 만들 수 있는 권한이 없습니다.
- 앱이 있는 것과 다른 Microsoft Entra 테넌트의 앱 등록을 사용하려고 합니다.
- 정부 클라우드에서는 새 등록을 만드는 옵션을 사용할 수 없습니다.
새 앱 등록(옵션 1)을 만들고 사용하거나 별도로 만든 기존 등록을 사용할 수 있습니다(옵션 2).
옵션 1: 앱 등록을 새로 만들어 사용
앱 등록을 별도로 만들 필요가 없는 경우 이 옵션을 사용합니다. 앱 등록을 만든 후 Microsoft Entra에서 사용자 지정할 수 있습니다.
참고 항목
정부 클라우드에서는 새 등록을 자동으로 만드는 옵션을 사용할 수 없습니다. 대신 등록을 별도로 정의합니다.
새 앱 등록 만들기를 선택합니다.
새 앱 등록의 이름을 입력합니다.
지원하는 계정 유형을 선택합니다.
- 현재 테넌트 - 단일 테넌트. 이 조직 디렉터리의 계정만 해당. 디렉터리의 모든 사용자 및 게스트 계정은 사용자의 애플리케이션 또는 API를 사용할 수 있습니다. 대상 그룹이 조직 내부자인 경우 이 옵션을 사용합니다.
- 모든 Microsoft Entra 디렉터리 - 다중 테넌트. 모든 조직 디렉터리의 계정. Microsoft의 회사 또는 학교 계정이 있는 모든 사용자는 사용자의 애플리케이션이나 API를 사용할 수 있습니다. 이러한 계정에는 Office 365를 사용하는 학교와 기업이 포함됩니다. 대상 그룹이 비즈니스 또는 교육 고객이며 다중 테넌트를 사용하도록 설정하려면 이 옵션을 사용합니다.
- 모든 Microsoft Entra 디렉터리 및 개인 Microsoft 계정. 모든 조직 디렉터리 계정 및 개인 Microsoft 계정(예: Skype, Xbox). 회사 또는 학교나 개인 Microsoft 계정을 가진 모든 사용자는 애플리케이션 또는 API를 사용할 수 있습니다. Skype 및 Xbox와 같은 서비스에 로그인하는 데 사용되는 개인 계정뿐만 아니라 Office 365를 사용하는 학교 및 회사가 포함됩니다. 가장 폭넓은 Microsoft ID 집합을 대상으로 지정하고 다중 테넌트를 사용하도록 설정하려면 이 옵션을 사용합니다.
- 개인 Microsoft 계정만. Xbox 및 Skype와 같은 서비스에 로그인하는 데 사용되는 개인 계정 가장 폭넓은 Microsoft ID 집합을 대상으로 하려면 이 옵션을 사용합니다.
원하는 경우 나중에 등록의 이름 또는 지원되는 계정 유형을 변경할 수 있습니다.
클라이언트 비밀은 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET으로 명명된 슬롯 고정이란 애플리케이션 설정으로 생성됩니다. Azure Key Vault에서 비밀을 관리하려는 경우 나중에 Key Vault 참조를 사용하도록 해당 설정을 업데이트할 수 있습니다.
옵션 2: 별도로 만든 기존 등록 사용
다음 중 하나를 선택합니다.
이 디렉터리 에서 기존 앱 등록을 선택하고 드롭다운 목록에서 앱 등록을 선택합니다.
기존 앱 등록 의 세부 정보를 제공하고 다음을 제공합니다.
- 애플리케이션(클라이언트) ID입니다.
-
클라이언트 암호(권장). 토큰을 요청할 때 애플리케이션이 해당 ID를 증명하는 데 사용하는 비밀 값입니다. 이 값은 사용자의 앱 구성에 이름이
MICROSOFT_PROVIDER_AUTHENTICATION_SECRET인 슬롯 고정 애플리케이션 설정으로 저장됩니다. 클라이언트 암호가 설정되지 않은 경우 서비스의 로그인 작업은 권장되지 않는 OAuth 2.0 암시적 권한 부여 흐름을 사용합니다. -
형식
<authentication-endpoint>/<tenant-id>/v2.0을 취하는 발급자 URL입니다.<authentication-endpoint>를 인증 엔드포인트인 클라우드 환경 관련 값으로 대체합니다. 예를 들어 글로벌 Azure의 인력 테넌트는 "https://sts.windows.net"을 인증 엔드포인트로 사용합니다.
인력 테넌트에서 앱 등록을 수동으로 만들어야 하는 경우 Microsoft ID 플랫폼 애플리케이션 등록을 참조하세요. 등록 프로세스를 진행하면서 애플리케이션(클라이언트) ID 및 클라이언트 암호 값을 확실히 기록해 둡니다.
등록 프로세스 중에 리디렉션 URI 섹션에서 플랫폼으로 웹을 선택하고 <app-url>/.auth/login/aad/callback을 입력합니다. 예들 들어 https://contoso.azurewebsites.net/.auth/login/aad/callback입니다.
앱 등록을 다 만들었다면 수정합니다.
왼쪽 탐색 영역에서 API 표시>추가>저장을 차례로 선택합니다. 이 값은 리소스로 사용될 때 애플리케이션을 고유하게 식별하며, 이를 통해 액세스 권한을 부여하는 토큰을 요청할 수 있습니다. 값은 만드는 범위에 대한 접두사입니다.
단일 테넌트 앱의 경우 양식
api://<application-client-id>에 있는 기본값을 사용할 수 있습니다. 테넌트에 대해 확인된 도메인 중 하나를 기반으로 보다 읽기 쉬운 URI(예:https://contoso.com/api)를 지정할 수도 있습니다. 다중 테넌트 앱의 경우 사용자 지정 URI를 제공해야 합니다. 앱 ID URI에 허용되는 형식에 대한 자세한 내용은 Microsoft Entra ID의 애플리케이션 속성에 대한 보안 모범 사례를 참조하세요.범위 추가를 선택합니다.
- 범위 이름에 user_impersonation을 입력합니다.
- 사용자가 이 범위에 동의하도록 허용하려면 동의할 수 있는 사람에서 관리자 및 사용자를 선택합니다.
- 동의 범위 이름을 입력합니다. 사용자가 동의 페이지에 표시할 설명을 입력합니다. 예를 들어 Access <애플리케이션 이름>을 입력합니다.
- 범위 추가를 선택합니다.
(권장) 클라이언트 암호를 만들려면 다음을 수행합니다.
- 왼쪽 탐색 영역에서 인증서 및 비밀>클라이언트 암호>새 클라이언트 암호를 차례로 선택합니다.
- 설명 및 만료를 입력하고 추가를 선택합니다.
- 값 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 다시 표시되지 않습니다.
(선택 사항) 회신 URL을 여러 개 추가하려면 인증을 선택합니다.
추가 검사 구성
추가 검사 에서는 애플리케이션에 액세스할 수 있는 요청을 결정합니다. 지금 이 동작을 사용자 지정하거나, 나중에 기본 인증 화면에서 인증 설정 옆의 편집을 선택하여 이 설정을 조정할 수 있습니다.
클라이언트 애플리케이션 요구 사항에는 다음의 수행 여부를 선택합니다.
- 이 애플리케이션 자체의 요청만 허용
- 특정 클라이언트 애플리케이션의 요청 허용
- 모든 애플리케이션의 요청 허용(권장하지 않음)
ID 요구 사항에는 다음의 수행 여부를 선택합니다.
- 모든 ID의 요청 허용
- 특정 ID의 요청 허용
테넌트 요구 사항에는 다음의 수행 여부를 선택합니다.
- 발급자 테넌트의 요청만 허용
- 특정 테넌트에서 요청 허용
- 발급자를 기반으로 기본 제한 사용
앱은 코드에서 다른 권한 부여 결정을 내려야 할 수도 있습니다. 자세한 내용은 기본 권한 부여 정책 사용을 참조하세요.
인증 설정 구성
이러한 옵션은 애플리케이션이 인증되지 않은 요청에 응답하는 방법을 결정합니다. 기본 선택 항목은 모든 요청을 리디렉션하여 이 새 공급자로 로그인합니다. 지금 이 동작의 사용자 지정을 변경하거나, 나중에 기본 인증 화면에서 인증 설정 옆의 편집을 선택하여 이 설정을 조정할 수 있습니다. 자세한 내용은 인증 흐름을 참조하세요.
액세스 제한에서는 다음의 수행 여부를 결정합니다.
- 인증 필요
- 인증되지 않은 액세스 허용
인증되지 않은 요청의 경우
- HTTP 302 리디렉션 찾음: 웹 사이트에 권장됨
- HTTP 401 권한 없음: API에 권장됨
- HTTP 403 사용할 수 없음
- HTTP 404 찾을 수 없음
토큰 저장소를 선택합니다(권장됨). 토큰 저장소는 애플리케이션의 토큰을 수집하거나 저장하고 새로 고칩니다. 앱에 토큰이 필요하지 않거나 성능을 최적화해야 하는 경우 나중에 이 동작을 사용하지 않도록 설정할 수 있습니다.
ID 공급자 추가
인력 구성을 선택한 경우 다음: 권한을 선택하고 애플리케이션에 필요한 Microsoft Graph 권한을 추가할 수 있습니다. 이러한 권한은 앱 등록에 추가되지만 나중에 변경할 수도 있습니다. 외부 구성을 선택한 경우 나중에 Microsoft Graph 권한을 추가할 수 있습니다.
- 추가를 선택합니다.
이제 앱에서 인증을 위해 Microsoft ID 플랫폼을 사용할 준비가 되었습니다. 공급자는 인증 화면에 나열됩니다. 여기에서 공급자 구성을 편집하거나 삭제할 수 있습니다.
Azure Storage 및 Microsoft Graph에 액세스하는 웹앱에 대한 Microsoft Entra 로그인을 구성하는 예제는 웹앱에 앱 인증 추가를 참조하세요.
요청 권한 부여
기본적으로 App Service 인증은 인증만 처리합니다. 호출자가 그들이 말하는 사람인지 여부를 결정합니다. 해당 호출자가 일부 리소스에 액세스할 수 있어야 하는지 여부를 결정하는 권한 부여는 인증을 넘어서는 단계입니다. 자세한 내용은 권한 부여 기본 사항을 참조 하세요.
앱은 코드에서 권한 부여를 결정할 수 있습니다. App Service 인증은 몇 가지 기본 제공 검사를 제공하므로 도움이 될 수 있지만 앱의 권한 부여 요구 사항을 충족하기에는 충분하지 않을 수 있습니다.
팁
다중 테넌트 애플리케이션은 이 프로세스의 일부로 요청의 발급자 및 테넌트 ID의 유효성을 검사하여 값이 허용되는지 확인해야 합니다. App Service 인증이 다중 테넌트 시나리오에 대해 구성된 경우 요청이 들어오는 테넌트의 유효성을 검사하지 않습니다. 예를 들어 조직이 서비스에 등록한 경우를 기준으로 앱을 특정 테넌트로 제한해야 할 수 있습니다. 여러 발급자 값을 처리하려면 코드 업데이트를 참조하세요.
애플리케이션 코드에서 유효성 검사 수행
앱 코드에서 권한 부여 검사를 수행하는 경우 App Service 인증에서 사용할 수 있는 클레임 정보를 활용할 수 있습니다. 자세한 내용은 앱 코드에서 Access 사용자 클레임을 참조 하세요.
삽입된 x-ms-client-principal 헤더에는 호출자에 대해 어설션된 클레임이 포함된 Base64로 인코딩된 JSON 개체가 포함됩니다. 기본적으로 이러한 클레임은 클레임 매핑을 거치므로 클레임 이름이 토큰에 표시되는 것과 항상 일치하지 않을 수 있습니다. 예를 들어 tid 클레임은 http://schemas.microsoft.com/identity/claims/tenantid에 대신 매핑됩니다.
삽입된 x-ms-token-aad-access-token 헤더에서 기본 액세스 토큰을 사용하여 직접 작업할 수도 있습니다.
기본 제공 권한 부여 정책 사용
만든 앱 등록은 Microsoft Entra 테넌트에 대한 수신 요청을 인증합니다. 기본적으로 테넌트 내의 모든 사용자가 애플리케이션에 액세스할 수 있습니다. 이 방법은 많은 애플리케이션에 적합합니다. 일부 애플리케이션은 권한 부여 결정을 내려 액세스를 추가로 제한해야 합니다. 애플리케이션 코드는 사용자 지정 권한 부여 논리를 처리하기에 가장 좋은 위치인 경우가 많습니다. 그러나 일반적인 시나리오의 경우 Microsoft ID 플랫폼에서 액세스를 제한하는 데 사용할 수 있는 기본 제공 검사를 제공합니다.
이 섹션에서는 App Service 인증 V2 API를 사용하여 기본 제공 검사를 사용하도록 설정하는 방법을 보여 줍니다. 현재 이러한 기본 제공 검사를 구성하는 유일한 방법은 Azure Resource Manager 템플릿 또는 REST API를사용하는 것입니다.
API 개체 내에서 Microsoft Entra ID 공급자 구성에는 다음 구조와 같이 defaultAuthorizationPolicy 개체를 포함할 수 있는 validation 섹션이 있습니다.
{
"validation": {
"defaultAuthorizationPolicy": {
"allowedApplications": [],
"allowedPrincipals": {
"identities": []
}
}
}
}
또한 사용 중인 API 버전에 관계없이 애플리케이션 설정을 통해 일부 검사를 구성할 수 있습니다. 애플리케이션 설정은 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 쉼표로 구분된 최대 10개의 테넌트 ID 목록(예: aaaabbbb-0000-cccc-1111-dddd2222eeee)으로 구성할 수 있습니다.
이 설정을 사용하려면 클레임에서 지정한 대로 지정된 테넌트 중 하나에서 들어오는 토큰이 있어야 할 tid 수 있습니다.
WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL 애플리케이션 설정을 구성 true 하거나 1 클레임을 포함 oid 하도록 들어오는 토큰을 요구할 수 있습니다. 구성된 경우 allowedPrincipals.identities 이 제공된 ID 목록에 대해 클레임이 검사되므로 이 설정이 무시되고 true oid 로 처리됩니다.
이러한 기본 제공 확인에 실패한 요청에는 HTTP 403 Forbidden 응답이 제공됩니다.
App Service에 액세스하도록 클라이언트 앱 구성
이전 섹션에서는 사용자를 인증하기 위해 App Service 또는 Azure Function을 등록했습니다. 이 섹션에서는 Microsoft Entra에서 네이티브 클라이언트 또는 디먼 앱을 등록하는 방법을 설명합니다. N 계층 아키텍처와 같이 사용자 또는 자신을 대신하여 App Service에서 노출하는 API에 대한 액세스를 요청할 수 있습니다. 사용자만 인증하려는 경우 이 섹션의 단계는 필요하지 않습니다.
네이티브 클라이언트 애플리케이션
로그인한 사용자를 대신하여 App Service 앱의 API에 대한 액세스를 요청하도록 네이티브 클라이언트를 등록할 수 있습니다.
포털 메뉴에서 Microsoft Entra ID를 선택합니다.
왼쪽 탐색 창에서 관리>앱 등록, 새 등록을 선택합니다.
애플리케이션 등록 페이지에서 앱 등록의 이름을 입력합니다.
리디렉션 URI에서 공용 클라이언트/네이티브(모바일 및 데스크톱)를 선택하고 URL
<app-url>/.auth/login/aad/callback을 입력합니다. 예들 들어https://contoso.azurewebsites.net/.auth/login/aad/callback입니다.등록을 선택합니다.
앱 등록을 만든 후에는 애플리케이션(클라이언트) ID의 값을 복사합니다.
참고 항목
Microsoft Store 애플리케이션의 경우 URI로 패키지 SID를 대신 사용합니다.
왼쪽 탐색 창에서 API 권한 관리를>선택합니다. 그런 다음, 권한 내 API 추가를>선택합니다.
앞에서 App Service 앱에 대해 만든 앱 등록을 선택합니다. 앱 등록이 표시되지 않으면 앱 등록에 user_impersonation 범위를 추가해야 합니다.
위임된 권한에서 user_impersonation을 선택한 다음, 사용 권한 추가를 선택합니다.
사용자를 대신하여 App Service 앱에 대한 액세스를 요청할 수 있는 네이티브 클라이언트 애플리케이션을 구성했습니다.
디먼 클라이언트 애플리케이션(서비스 간 호출)
N 계층 아키텍처에서 클라이언트 애플리케이션은 사용자를 대신하지 않고 클라이언트 앱 자체를 대신하여 App Service 또는 함수 앱을 호출하는 토큰을 획득할 수 있습니다. 이 시나리오는 로그인한 사용자가 없는 상태에서 작업을 수행하는 비대화형 디먼 애플리케이션에 유용합니다. 이 파일은 표준 OAuth 2.0 클라이언트 자격 증명 권한 부여를 사용합니다. 자세한 내용은 Microsoft ID 플랫폼 및 OAuth 2.0 클라이언트 자격 증명 흐름을 참조하세요.
- Azure Portal 메뉴에서 Microsoft Entra ID를 선택합니다.
- 왼쪽 탐색 창에서 관리>앱 등록>새 등록을 선택합니다.
- 애플리케이션 등록 페이지에서 앱 등록의 이름을 입력합니다.
- 디먼 애플리케이션의 경우에는 리디렉션 URI가 필요하지 않으므로 비워 둘 수 있습니다.
- 등록을 선택합니다.
- 앱 등록을 만든 후에는 애플리케이션(클라이언트) ID의 값을 복사합니다.
- 왼쪽 탐색 창에서 인증서 및 비밀 관리를>선택합니다. 그런 다음 클라이언트 비밀>새 클라이언트 비밀을 선택합니다.
- 설명 및 만료를 입력하고 추가를 선택합니다.
- 값 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 다시 표시되지 않습니다.
이제 클라이언트 ID 및 클라이언트 암호를 사용하여 액세스 토큰을 요청할 수 있습니다. 매개 변수를 resource 대상 앱의 애플리케이션 ID URI 로 설정합니다. 그런 다음, 표준 OAuth 2.0 권한 부여 헤더를 사용하여 결과 액세스 토큰을 대상 앱에 표시할 수 있습니다. App Service 인증은 평소와 같이 토큰의 유효성을 검사하고 사용하여 호출자가 인증되었음을 나타냅니다. 이 경우 호출자는 사용자가 아닌 애플리케이션입니다.
이 방법을 사용하면 Microsoft Entra 테넌트에 있는 모든 클라이언트 애플리케이션이 액세스 토큰을 요청하고 대상 앱에 인증할 수 있습니다. 또한 특정 클라이언트 애플리케이션만 허용하도록 권한 부여를 적용하려면 추가 구성을 수행해야 합니다.
권한을 부여해야 하는 클라이언트를 나타내는 앱 등록에서 API 권한>내 API 권한> 추가를 선택합니다.
이전에 만든 앱 등록을 선택합니다. 앱 등록이 표시되지 않으면 앱 역할을 추가했는지 확인합니다.
애플리케이션 사용 권한에서 이전에 만든 앱 역할을 선택합니다. 사용 권한 추가를 선택합니다.
권한을 요청하도록 클라이언트 애플리케이션에 권한을 부여하려면 관리자 동의 부여를 선택해야 합니다.
이전 시나리오(어떤 역할도 추가되기 전)와 마찬가지로 이제 동일한 대상
resource에 대한 액세스 토큰을 요청하면, 액세스 토큰에는 클라이언트 애플리케이션에 대한 권한이 부여된 앱 역할을 포함하는roles클레임이 포함됩니다.
이제 대상 App Service 또는 함수 앱 코드 내에서 토큰에 필요한 역할이 있는지 확인할 수 있습니다. App Service 인증은 이 유효성 검사를 수행하지 않습니다. 자세한 내용은 사용자 클레임 액세스를 참조하세요.
자체 ID를 사용하여 App Service 앱에 액세스할 수 있는 디먼 클라이언트 애플리케이션을 구성했습니다.
모범 사례
인증을 설정하는 데 사용하는 구성에 관계 없이 다음 모범 사례를 통해 테넌트 및 애플리케이션의 보안을 유지할 수 있습니다.
- Microsoft Entra에서 자체 앱 등록을 사용하여 각 App Service 앱을 구성합니다.
- 각 App Service 앱에 고유한 권한 및 동의를 제공합니다.
- 환경 간에 사용 권한 공유를 방지합니다. 별도의 배포 슬롯에 대해 별도의 앱 등록을 사용합니다. 이렇게 하면 새 코드를 테스트할 때 문제가 프로덕션 앱에 영향을 주는 것을 방지할 수 있습니다.
Microsoft Graph로 마이그레이션
일부 이전 앱은 사용되지 않는 Azure AD Graph에 대한 종속성으로 설정될 수 있으며, 이 앱을 완전히 사용 중지하도록 예약되어 있습니다. 예를 들어 앱 코드는 Azure AD Graph를 호출하여 미들웨어 파이프라인에서 권한 부여 필터의 일부로 그룹 멤버 자격을 확인할 수 있습니다. 앱은 Microsoft Graph로 이동해야 합니다. 자세한 내용은 Azure AD Graph에서 Microsoft Graph로 앱 마이그레이션을 참조하세요.
이 마이그레이션 중에 App Service 인증 구성을 일부 변경해야 할 수 있습니다. 앱 등록에 Microsoft Graph 권한을 추가한 후 다음을 수행할 수 있습니다.
아직 접미사가 포함되지 않은 경우 발급자 URL을
/v2.0업데이트합니다.로그인 구성에서 Azure AD Graph 사용 권한에 대한 요청을 제거합니다. 변경할 속성은 사용 중인 관리 API 버전에에 따라 달라집니다.
- V1 API(
/authsettings)를 사용하는 경우 이 설정은 배열에additionalLoginParams있습니다. - V2 API(
/authsettingsV2)를 사용하는 경우 이 설정은 배열에loginParameters있습니다.
예를 들어 참조를
https://graph.windows.net제거해야 합니다. 이 변경에는 엔드포인트에서 지원/v2.0되지 않는 매개 변수 또는 Azure AD Graph에서 특별히 요청한 범위가 포함resource됩니다.또한 애플리케이션 등록을 위해 설정한 새 Microsoft Graph 권한을 요청하도록 구성을 업데이트해야 합니다. 대부분의 경우 .default scope을 사용하여 이 설정을 간소화할 수 있습니다. 이렇게 하려면 새 로그인 매개 변수
scope=openid profile email https://graph.microsoft.com/.default를 추가합니다.- V1 API(
이러한 변경으로 App Service 인증이 로그인을 시도할 때 더 이상 Azure AD Graph에 대한 권한을 요청하지 않습니다. 대신 Microsoft Graph에 대한 토큰을 가져옵니다. Azure AD Graph에서 Microsoft Graph로 앱 마이그레이션에 설명된 대로 애플리케이션 코드에서 해당 토큰의 모든 사용도 업데이트해야 합니다.