Microsoft Entra 로그인을 사용하도록 App Service 또는 Azure Functions 앱 구성

다른 인증 공급자를 선택하여 해당 공급자로 이동합니다.

이 문서에서는 앱이 인증 공급자로 Microsoft ID 플랫폼(Microsoft Entra ID)을 사용하여 사용자를 로그인하도록 Azure App Service 또는 Azure Functions에 대한 인증을 구성하는 방법을 보여 줍니다.

App Service 인증 기능은 Microsoft ID 플랫폼을 사용하여 앱 등록을 자동으로 만들 수 있습니다. 사용자 또는 디렉터리 관리자가 별도로 만든 등록을 사용할 수도 있습니다.

참고 항목

새 등록을 자동으로 만드는 옵션은 정부 클라우드에서나 [고객용 Microsoft Entra ID(미리 보기)]를 사용할 때는 사용할 수 없습니다. 대신 등록을 별도로 정의합니다.

옵션 1: 자동으로 새 앱 등록 만들기

앱 등록을 별도로 만들 필요가 없는 경우 이 옵션을 사용합니다. 앱 등록이 만들어지면 Microsoft Entra ID에서 이를 사용자 지정할 수 있습니다.

  1. Azure Portal에 로그인하고 IoT Hub로 이동합니다.

  2. 왼쪽 메뉴에서 인증을 선택합니다. ID 공급자 추가를 선택합니다.

  3. ID 공급자 드롭다운에서 Microsoft를 선택합니다. 새 등록을 만드는 옵션이 기본적으로 선택되어 있습니다. 등록의 이름 또는 지원되는 계정 유형을 변경할 수 있습니다.

    클라이언트 암호는 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET라는 슬롯 고정 애플리케이션 설정으로 만들어지고 저장됩니다. Azure Key Vault에서 비밀을 관리하려는 경우 나중에 Key Vault 참조를 사용하도록 해당 설정을 업데이트할 수 있습니다.

  4. 이것이 애플리케이션에 대해 구성된 첫 번째 ID 공급자인 경우 App Service 인증 설정 섹션도 표시됩니다. 그렇지 않으면 다음 단계로 이동할 수 있습니다.

    이러한 옵션은 애플리케이션이 인증되지 않은 요청에 응답하는 방법을 결정하며 기본 선택 항목은 이 새 공급자를 사용하여 로그인하도록 모든 요청을 리디렉션합니다. 지금 이 동작의 사용자 지정을 변경하거나, 나중에 기본 인증 화면에서 인증 설정 옆의 편집을 선택하여 이 설정을 조정할 수 있습니다. 이러한 옵션에 대한 자세한 정보는 인증 흐름을 참조하세요.

  5. (선택 사항) 다음: 권한을 선택하고 애플리케이션에 필요한 Microsoft Graph 권한을 추가합니다. 이러한 항목은 앱 등록에 추가되지만 나중에 변경할 수도 있습니다.

  6. 추가를 선택합니다.

이제 앱에서 인증을 위해 Microsoft ID 플랫폼을 사용할 준비가 되었습니다. 공급자는 인증 화면에 나열됩니다. 여기에서 공급자 구성을 편집하거나 삭제할 수 있습니다.

Azure Storage 및 Microsoft Graph에 액세스하는 웹앱에 대해 Microsoft Entra 로그인을 구성하는 예제는 이 자습서를 참조하세요.

옵션 2: 별도로 만든 기존 등록 사용

기존 앱 등록을 사용하도록 App Service 인증을 구성할 수 있습니다. 기존 앱 등록을 사용하는 가장 일반적인 경우는 다음과 같습니다.

  • 계정에 Microsoft Entra 테넌트에서 앱 등록을 만들 수 있는 권한이 없습니다.
  • 앱이 있는 것과 다른 Microsoft Entra 테넌트의 앱 등록을 사용하려고 합니다.
  • 정부 클라우드에서는 새 등록을 만드는 옵션을 사용할 수 없습니다.

1단계: Microsoft Entra ID에서 App Service 앱에 대한 앱 등록 만들기

앱 등록을 만드는 동안 나중에 App Service 앱에서 인증을 구성할 때 필요한 다음 정보를 수집합니다.

  • Client ID
  • 테넌트 ID
  • 클라이언트 암호(선택 사항이지만 권장됨)
  • 응용 프로그램 ID URI

앱 등록을 만드는 지침은 직원 테넌트 또는 고객 테넌트를 사용하는 경우에 따라 달라집니다. 아래 탭을 사용하여 시나리오에 적합한 지침 집합을 선택합니다.

앱을 등록하려면 다음 단계를 수행합니다.

  1. Azure Portal에 로그인하고 App Services를 검색하여 선택한 다음, 자신의 앱을 선택합니다. 앱 URL을 적어 둡니다. 이를 사용하여 Microsoft Entra 앱 등록을 구성합니다.

  2. 포털에서 사용 중인 테넌트로 이동합니다.

    포털 메뉴에서 Microsoft Entra ID를 선택합니다. 사용 중인 테넌트가 App Service 애플리케이션을 구성하는 데 사용하는 테넌트와 다른 경우 먼저 디렉터리를 변경해야 합니다.

  3. "개요" 화면에서 테넌트 ID주 도메인을 기록해 둡니다.

  4. 왼쪽 탐색 영역에서 앱 등록>새 등록을 차례로 선택합니다.

  5. 애플리케이션 등록 페이지에서 앱 등록의 이름을 입력합니다.

  6. 지원되는 계정 유형에서 이 애플리케이션에 액세스할 수 있는 계정 유형을 선택합니다.

  7. 리디렉션 URI 섹션에서 플랫폼으로 을 선택하고 <app-url>/.auth/login/aad/callback을 입력합니다. 예: https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. 등록을 선택합니다.

  9. 앱 등록을 만든 후에는 나중에 사용할 수 있도록 애플리케이션(클라이언트) ID디렉터리(테넌트) ID를 복사합니다.

  10. 암시적 권한 부여 및 하이브리드 흐름에서 ID 토큰을 사용하도록 설정하여 OpenID Connect 사용자가 App Service에서 로그인하는 것을 허용합니다. 저장을 선택합니다.

  11. (선택 사항) 왼쪽 탐색 영역에서 브랜딩 및 속성을 선택합니다. 홈페이지 URL에서 App Service 앱의 URL을 입력하고 저장을 선택합니다.

  12. 왼쪽 탐색 영역에서 API 표시>설정>저장을 차례로 선택합니다. 이 값은 리소스로 사용될 때 애플리케이션을 고유하게 식별하여 액세스 권한을 부여하는 토큰을 요청할 수 있도록 합니다. 만드는 범위에 대한 접두사로 사용됩니다.

    단일 테넌트 앱의 경우 양식 api://<application-client-id>에 있는 기본값을 사용할 수 있습니다. 테넌트에 대해 확인된 도메인 중 하나를 기반으로 보다 읽기 쉬운 URI(예: https://contoso.com/api)를 지정할 수도 있습니다. 다중 테넌트 앱의 경우 사용자 지정 URI를 제공해야 합니다. 앱 ID URI에 허용되는 형식에 대한 자세한 내용은 앱 등록 모범 사례 참조를 참조하세요.

  13. 범위 추가를 선택합니다.

    1. 범위 이름user_impersonation을 입력합니다.
    2. 사용자가 이 범위에 동의하도록 허용하려면 동의할 수 있는 사람에서 관리자 및 사용자를 선택합니다.
    3. 텍스트 상자에는 동의 페이지에서 사용자에게 표시할 동의 범위 이름 및 설명을 입력합니다. 예를 들어 Access <애플리케이션 이름>을 입력합니다.
    4. 범위 추가를 선택합니다.
  14. (선택 사항) 클라이언트 암호를 만들려면 다음을 수행합니다.

    1. 왼쪽 탐색 영역에서 인증서 및 비밀>클라이언트 암호>새 클라이언트 암호를 차례로 선택합니다.
    2. 설명 및 만료를 입력하고 추가를 선택합니다.
    3. 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 해당 값이 다시 표시되지 않습니다.
  15. (선택 사항) 회신 URL을 여러 개 추가하려면 인증을 선택합니다.

  16. 앱 등록 설정을 완료합니다.

    인력 테넌트에는 다른 단계가 필요하지 않습니다.

2단계: App Service 앱에서 Microsoft Entra ID 사용

  1. Azure Portal에 로그인하고 IoT Hub로 이동합니다.

  2. 왼쪽 탐색 영역에서 인증>ID 공급자 추가>Microsoft를 차례로 선택합니다.

  3. 만든 앱 등록의 테넌트 유형을 선택합니다.

  4. 적절한 테넌트 유형에 대한 지침을 사용하여 만든 등록을 사용하도록 앱을 구성합니다.

    앱 등록 유형에 대해 다음 중 하나를 선택합니다.

    • 이 디렉터리에서 기존 앱 등록 선택: 현재 테넌트에서 앱 등록을 선택하고 필요한 앱 정보를 자동으로 수집합니다. 시스템은 앱 등록에 대해 새 클라이언트 암호를 만들고 앱을 사용하도록 자동으로 구성합니다. 기본 발급자 URL은 앱 등록에 구성된 지원되는 계정 유형에 따라 설정됩니다. 이 기본값을 변경하려면 다음 표를 참조하세요.
    • 기존 앱 등록 세부 정보 제공: 다른 테넌트의 앱 등록 세부 정보를 지정하거나 현재 테넌트에서 등록을 쿼리할 수 있는 권한이 계정에 없는 경우 지정합니다. 이 옵션의 경우 다음 표에 따라 수동으로 구성 값을 입력해야 합니다.

    인력 테넌트의 인증 엔드포인트클라우드 환경과 관련된 값이어야 합니다. 예를 들어 글로벌 Azure의 인력 테넌트는 "https://login.microsoftonline.com"을 인증 엔드포인트로 사용합니다. 올바른 발급자 URL을 생성하는 데 필요하므로 인증 엔드포인트 값을 기록해 둡니다.

    구성 세부 정보를 직접 입력할 때 앱 등록 생성 프로세스 중에 수집한 값을 사용합니다.

    필드 설명
    애플리케이션(클라이언트) ID 앱 등록의 애플리케이션(클라이언트) ID를 사용합니다.
    클라이언트 암호 앱 등록에서 생성한 클라이언트 암호를 사용합니다. 클라이언트 비밀을 사용하면 하이브리드 흐름이 사용되며 App Service는 액세스 및 새로 고침 토큰을 반환합니다. 클라이언트 암호를 설정하지 않으면 암시적 흐름이 사용되며 ID 토큰만 반환됩니다. 이러한 토큰은 공급자가 보내고 App Service 인증 토큰 저장소에 저장됩니다.
    발급자 URL <authentication-endpoint>/<tenant-id>/v2.0을 사용하고 <인증 엔드포인트>를 테넌트 유형 및 클라우드 환경에 대해 이전 단계에서 결정한 인증 엔드포인트로 바꾸고, <테넌트 ID>도 앱 등록이 만들어진 디렉터리(테넌트) ID로 바꿉니다. Azure AD v1을 사용하는 애플리케이션의 경우 URL에서 /v2.0을 생략합니다.

    이 값은 사용자를 올바른 Microsoft Entra 테넌트로 리디렉션하고 적절한 메타데이터를 다운로드하여 적절한 토큰 서명 키와 토큰 발급자 클레임 값을 확인하는 등의 용도로 사용됩니다. 테넌트별 엔드포인트 이외의 모든 구성은 다중 테넌트로 처리됩니다. 다중 테넌트 구성에서는 시스템에서 발급자 또는 테넌트 ID에 대한 유효성 검사를 수행하지 않으며, 이러한 검사는 앱의 권한 부여 논리에서 완전히 처리되어야 합니다.
    허용되는 토큰 대상 이 필드는 선택적입니다. 구성된 애플리케이션(클라이언트) ID는 암시적으로 항상 허용되는 대상으로 간주됩니다. 애플리케이션이 다른 클라이언트에서 호출할 API를 나타내는 경우 앱 등록에서 구성한 애플리케이션 ID URI도 추가해야 합니다. 허용되는 대상 그룹 목록에는 총 500자 제한이 있습니다.

    클라이언트 비밀은 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET으로 명명된 슬롯 고정이란 애플리케이션 설정으로 저장됩니다. Azure Key Vault에서 비밀을 관리하려는 경우 나중에 Key Vault 참조를 사용하도록 해당 설정을 업데이트할 수 있습니다.

  5. 이것이 애플리케이션에 대해 구성된 첫 번째 ID 공급자인 경우 App Service 인증 설정 섹션도 표시됩니다. 그렇지 않으면 다음 단계로 이동할 수 있습니다.

    이러한 옵션은 애플리케이션이 인증되지 않은 요청에 응답하는 방법을 결정하며 기본 선택 항목은 이 새 공급자를 사용하여 로그인하도록 모든 요청을 리디렉션합니다. 지금 이 동작의 사용자 지정을 변경하거나, 나중에 기본 인증 화면에서 인증 설정 옆의 편집을 선택하여 이 설정을 조정할 수 있습니다. 이러한 옵션에 대한 자세한 정보는 인증 흐름을 참조하세요.

  6. 추가를 선택합니다.

이제 앱에서 인증을 위해 Microsoft ID 플랫폼을 사용할 준비가 되었습니다. 공급자는 인증 화면에 나열됩니다. 여기에서 공급자 구성을 편집하거나 삭제할 수 있습니다.

요청 권한 부여

기본적으로 App Service 인증은 인증만 처리하여 호출자가 사용자가 누구인지 확인합니다. 해당 호출자가 일부 리소스에 액세스해야 하는지 여부를 결정하는 권한 부여는 인증 이상의 추가 단계입니다. Microsoft ID 플랫폼 권한 부여 기본 사항에서 이러한 개념에 대해 자세히 알아볼 수 있습니다.

앱은 코드에서 권한 부여를 결정할 수 있습니다. App Service 인증은 도움이 될 수 있는 몇 가지 기본 제공 검사를 제공하지만, 앱의 권한 부여 요구 사항을 충족하는 데 충분하지 않을 수 있습니다.

다중 테넌트 애플리케이션은 이 프로세스의 일환으로 요청의 발급자 및 테넌트 ID의 유효성을 검사하여 값이 허용되는지 확인해야 합니다. App Service 인증이 다중 테넌트 시나리오에 대해 구성되면 요청을 제공하는 테넌트의 유효성을 검사하지 않습니다. 예를 들어 조직에서 서비스에 등록했는지 여부에 따라 앱을 특정 테넌트로 제한해야 할 수 있습니다. Microsoft ID 플랫폼 다중 테넌트 지침을 참조하세요.

애플리케이션 코드에서 유효성 검사 수행

앱 코드에서 권한 부여 검사를 수행하는 경우 App Service 인증에서 사용할 수 있는 클레임 정보를 활용할 수 있습니다. 삽입된 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": []
            }
        }
    }
}
속성 설명
defaultAuthorizationPolicy 앱에 액세스하기 위해 충족해야 하는 요구 사항 그룹입니다. 구성된 각 속성에 대한 논리적 AND를 기반으로 액세스 권한이 부여됩니다. allowedApplicationsallowedPrincipals가 모두 구성된 경우 수신 요청이 수락되려면 두 요구 사항을 모두 충족해야 합니다.
allowedApplications 앱을 호출하는 클라이언트 리소스를 나타내는 문자열 애플리케이션 클라이언트 ID의 허용 목록입니다. 이 속성이 비어 있지 않은 배열로 구성된 경우 목록에 지정된 애플리케이션에서 얻은 토큰만 허용됩니다.

이 정책은 액세스 토큰이어야 하는 수신 토큰의 appid 또는 azp 클레임을 평가합니다. Microsoft ID 플랫폼 클레임 참조를 확인합니다.
allowedPrincipals 들어오는 요청이 나타내는 주체가 앱에 액세스할 수 있는지 여부를 결정하는 검사 그룹입니다. allowedPrincipals의 만족은 구성된 속성에 대한 논리적 OR를 기반으로 합니다.
identities(allowedPrincipals 아래) 액세스 권한이 있는 사용자 또는 애플리케이션을 나타내는 문자열 개체 ID의 허용 목록입니다. 이 속성이 비어 있지 않은 배열로 구성된 경우 요청이 나타내는 사용자 또는 애플리케이션이 목록에 지정된 경우 allowedPrincipals 요구 사항이 충족될 수 있습니다. ID 목록에는 총 500자 제한이 있습니다.

이 정책은 수신 토큰의 oid 클레임을 평가합니다. Microsoft ID 플랫폼 클레임 참조를 확인합니다.

또한 일부 검사는 사용하는 API 버전에 관계없이 애플리케이션 설정을 통해 구성할 수 있습니다. 들어오는 토큰이 tid 클레임에서 지정한 대로 지정된 테넌트 중 하나에서 온 것임을 요구하기 위해 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 애플리케이션 설정은 쉼표로 구분된 최대 10개의 테넌트 ID(예: "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") 목록으로 구성할 수 있습니다. 들어오는 토큰에 oid 클레임을 포함하도록 요구하려면 WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL 애플리케이션 설정을 "true" 또는 "1"로 구성할 수 있습니다. allowedPrincipals.identities가 구성된 경우 이 설정은 무시되고 true로 처리됩니다(oid 클레임이 이 제공된 ID 목록에 대해 확인되기 때문).

이러한 기본 제공 확인에 실패한 요청에는 HTTP 403 Forbidden 응답이 제공됩니다.

App Service에 액세스하도록 클라이언트 앱 구성

이전 섹션에서는 사용자를 인증하기 위해 App Service 또는 Azure Function을 등록했습니다. 이 섹션에서는 사용자 또는 해당 서비스를 대신하여 App Service에서 공개하는 API에 대한 액세스를 요청할 수 있도록 Microsoft Entra ID에서 네이티브 클라이언트 또는 디먼 앱을 등록하는 방법을 설명합니다. 사용자를 인증하기만 하려는 경우에는 이 섹션의 단계를 완료하지 않아도 됩니다.

네이티브 클라이언트 애플리케이션

로그인한 사용자를 대신하여 App Service 앱의 API에 대한 액세스를 요청하도록 네이티브 클라이언트를 등록할 수 있습니다.

  1. 포털 메뉴에서 Microsoft Entra ID를 선택합니다.

  2. 왼쪽 탐색 영역에서 앱 등록>새 등록을 차례로 선택합니다.

  3. 애플리케이션 등록 페이지에서 앱 등록의 이름을 입력합니다.

  4. 리디렉션 URI에서 퍼블릭 클라이언트(모바일 및 데스크톱)를 선택하고 URL로 <app-url>/.auth/login/aad/callback을 입력합니다. 예: https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. 등록을 선택합니다.

  6. 앱 등록을 만든 후에는 애플리케이션(클라이언트) ID의 값을 복사합니다.

    참고 항목

    Microsoft Store 애플리케이션의 경우 URI로 패키지 SID를 대신 사용합니다.

  7. 왼쪽 탐색 영역에서 API 권한>권한 추가>내 API를 차례로 선택합니다.

  8. 앞에서 App Service 앱에 대해 만든 앱 등록을 선택합니다. 앱 등록이 표시되지 않으면 Microsoft Entra ID에서 App Service 앱의 앱 등록 만들기에서 user_impersonation 범위를 추가했는지 확인합니다.

  9. 위임된 권한에서 user_impersonation을 선택한 다음, 사용 권한 추가를 선택합니다.

사용자 대신 App Service 앱에 액세스하도록 요청할 수 있는 네이티브 클라이언트 애플리케이션 구성이 완료되었습니다.

디먼 클라이언트 애플리케이션(서비스 간 호출)

N 계층 아키텍처에서 클라이언트 애플리케이션은 사용자가 아니라 클라이언트 앱 자체를 대신하여 App Service 또는 함수 앱을 호출하는 토큰을 획득할 수 있습니다. 이 시나리오는 로그인한 사용자가 없는 상태에서 작업을 수행하는 비대화형 디먼 애플리케이션에 유용합니다. 이 파일은 표준 OAuth 2.0 클라이언트 자격 증명 권한 부여를 사용합니다.

  1. 포털 메뉴에서 Microsoft Entra ID를 선택합니다.
  2. 왼쪽 탐색 영역에서 앱 등록>새 등록을 차례로 선택합니다.
  3. 애플리케이션 등록 페이지에서 앱 등록의 이름을 입력합니다.
  4. 디먼 애플리케이션의 경우에는 리디렉션 URI가 필요하지 않으므로 비워 둘 수 있습니다.
  5. 등록을 선택합니다.
  6. 앱 등록을 만든 후에는 애플리케이션(클라이언트) ID의 값을 복사합니다.
  7. 왼쪽 탐색 영역에서 인증서 및 비밀>클라이언트 암호>새 클라이언트 암호를 차례로 선택합니다.
  8. 설명 및 만료를 입력하고 추가를 선택합니다.
  9. 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 해당 값이 다시 표시되지 않습니다.

이제 resource 매개 변수를 대상 앱의 애플리케이션 ID URI로 설정하여 클라이언트 ID 및 클라이언트 암호를 사용하여 액세스 토큰을 요청할 수 있습니다. 그런 다음, 결과 액세스 토큰이 표준 OAuth 2.0 권한 부여 헤더를 사용하여 대상 앱에 제공될 수 있으며, App Service 인증은 평소와 같이 토큰의 유효성을 검사하고 해당 토큰을 사용하여 이제 호출자(이 경우 사용자가 아닌 애플리케이션)가 인증되었음을 나타냅니다.

현재 이 기능을 사용하면 Microsoft Entra 테넌트의 모든 클라이언트 애플리케이션이 액세스 토큰을 요청하고 대상 앱에 대한 인증을 수행할 수 있습니다. 특정 클라이언트 애플리케이션만 허용하도록 권한 부여를 적용하려면 몇 가지 추가 구성을 수행해야 합니다.

  1. 보호하려는 App Service 또는 함수 앱을 나타내는 앱 등록의 매니페스트에서 앱 역할을 정의합니다.
  2. 권한이 부여되어야 하는 클라이언트를 나타내는 앱 등록에서 API 사용 권한>사용 권한 추가>내 API를 선택합니다.
  3. 이전에 만든 앱 등록을 선택합니다. 앱 등록이 표시되지 않으면 앱 역할을 추가했는지 확인합니다.
  4. 애플리케이션 사용 권한에서 이전에 만든 앱 역할을 선택하고 사용 권한 추가를 선택합니다.
  5. 권한을 요청하도록 클라이언트 애플리케이션에 권한을 부여하려면 관리자 동의 부여를 선택해야 합니다.
  6. 이전 시나리오(어떤 역할도 추가되기 전)와 마찬가지로 이제 동일한 대상 resource에 대한 액세스 토큰을 요청하면, 액세스 토큰에는 클라이언트 애플리케이션에 대한 권한이 부여된 앱 역할을 포함하는 roles 클레임이 포함됩니다.
  7. 이제 대상 App Service 또는 함수 앱 코드 내에서 예상한 역할이 토큰에 있는지 확인할 수 있습니다(이 작업은 App Service 인증에서 수행되지 않음). 자세한 내용은 사용자 클레임 액세스를 참조하세요.

자체 ID를 사용하는 App Service 앱에 액세스할 수 있는 디먼 클라이언트 애플리케이션 구성이 완료되었습니다.

모범 사례

인증을 설정하는 데 사용하는 구성에 관계 없이 다음 모범 사례를 통해 테넌트 및 애플리케이션의 보안을 유지할 수 있습니다.

  • Microsoft Entra ID에서 자체 앱 등록을 사용하여 각 App Service 앱을 구성합니다.
  • 각 App Service 앱에 고유한 권한 및 동의를 제공합니다.
  • 환경 간에 권한을 공유하는 일이 없도록 배포 슬롯마다 별도의 앱 등록을 사용합니다. 이렇게 하면 새 코드를 테스트할 때 문제가 프로덕션 앱에 영향을 주는 것을 방지할 수 있습니다.

Microsoft Graph로 마이그레이션

몇몇 이전 앱은 사용되지 않는 Azure AD Graph에 대한 종속성으로 설정되었을 수도 있습니다. 이러한 앱은 완전히 사용 중지될 예정입니다. 예를 들어 앱 코드가 Azure AD Graph를 호출하여 미들웨어 파이프라인에서 권한 부여 필터의 일부로 그룹 구성원 자격을 확인했을 수 있습니다. Azure AD Graph 사용 중단 프로세스의 일부로 Microsoft Entra ID에서 제공하는 지침에 따라 앱을 Microsoft Graph로 이동해야 합니다. 이러한 지침에 따라 App Service 인증 구성을 일부 변경해야 할 수 있습니다. 앱 등록에 Microsoft Graph 사용 권한을 추가한 후에는 다음을 수행할 수 있습니다.

  1. 아직 "/v2.0" 접미사를 포함하지 않은 경우 이를 포함하도록 발급자 URL을 업데이트합니다.

  2. 로그인 구성에서 Azure AD Graph 사용 권한에 대한 요청을 제거합니다. 변경할 속성은 사용 중인 관리 API 버전에에 따라 달라집니다.

    • V1 API(/authsettings)를 사용하는 경우 이는 additionalLoginParams 배열에 있습니다.
    • V2 API(/authsettingsV2)를 사용하는 경우 이는 loginParameters 배열에 있습니다.

    예를 들어 "https://graph.windows.net"에 대한 참조를 제거해야 합니다. 여기에는 resource 매개 변수("/v2.0" 엔드포인트에서 지원되지 않음) 또는 Azure AD Graph에서 특별히 요청하는 범위가 포함됩니다.

    또한 애플리케이션 등록을 위해 설정한 새 Microsoft Graph 사용 권한을 요청하도록 구성을 업데이트해야 합니다. 대부분의 경우 .default scope을 사용하여 이 설정을 간소화할 수 있습니다. 이렇게 하려면 새 로그인 매개 변수 scope=openid profile email https://graph.microsoft.com/.default를 추가합니다.

이러한 변경 내용으로 App Service 인증에서 로그인을 시도하면 더 이상 Azure AD Graph에 대한 사용 권한을 요청하지 않고, 대신 Microsoft Graph에 대한 토큰을 가져옵니다. 또한, 애플리케이션 코드에서 해당 토큰을 사용하려면 Microsoft Entra ID에서 제공하는 지침에 따라 업데이트해야 합니다.

다음 단계