다음을 통해 공유

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에 대한 인증을 구성하는 방법을 보여 줍니다.

애플리케이션 및 애플리케이션 사용자 관련 테넌트 선택

애플리케이션에서 사용자가 로그인하도록 하려면 먼저 인력 또는 외부 테넌트에 등록해야 합니다. 직원 또는 비즈니스 게스트가 앱을 사용할 수 있도록 하는 경우 인력 테넌트에 앱을 등록합니다. 소비자 및 비즈니스 고객을 위한 앱인 경우 외부 테넌트에 등록합니다.

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

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

  3. ID 공급자 추가 페이지에서 ID 공급자로 Microsoft를 선택하여 Microsoft 및 Microsoft Entra ID에 로그인합니다.

  4. 테넌트 유형에서 직원 및 비즈니스 게스트용 인력 구성(현재 테넌트)을 선택하거나 소비자 및 비즈니스 고객용 외부 구성을 선택합니다.

앱 등록 선택하기

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

앱 등록을 별도로 만들 필요가 없는 경우라면 자동으로 새 앱 등록을 만듭니다. 원하는 경우 나중에 Microsoft Entra 관리 센터에서 앱 등록을 사용자 지정할 수 있습니다.

기존 앱 등록을 사용하는 가장 일반적인 경우는 다음과 같습니다.

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

앱 등록을 새로 만들어 사용하거나 별도로 만든 기존 등록을 사용합니다.

옵션 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"을 인증 엔드포인트로 사용합니다.

인력 테넌트에 수동으로 앱 등록을 만들어야 하는 경우, 애플리케이션 등록 빠른 시작을 따라 합니다. 등록 프로세스를 진행하면서 애플리케이션(클라이언트) ID 및 클라이언트 암호 값을 확실히 기록해 둡니다.

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

앱 등록을 다 만들었다면 수정합니다.

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

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

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

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

  3. (권장) 클라이언트 암호를 만들려면 다음을 수행합니다.

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

  4. (선택 사항) 회신 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 인증은 인증만 처리하여 호출자가 사용자가 누구인지 확인합니다. 해당 호출자가 일부 리소스에 액세스해야 하는지 여부를 결정하는 권한 부여는 인증 이상의 추가 단계입니다. 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를 기반으로 액세스 권한이 부여됩니다. allowedApplications 및 allowedPrincipals가 모두 구성된 경우 수신 요청이 수락되려면 두 요구 사항을 모두 충족해야 합니다.
allowedApplications 앱을 호출하는 클라이언트 리소스를 나타내는 문자열 애플리케이션 클라이언트 ID의 허용 목록입니다. 이 속성이 비어 있지 않은 배열로 구성된 경우 목록에 지정된 애플리케이션에서 얻은 토큰만 허용됩니다.

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

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

또한 일부 검사는 사용하는 API 버전에 관계없이 애플리케이션 설정을 통해 구성할 수 있습니다. 애플리케이션 설정은 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 최대 10개의 테넌트 ID(예: "aaaabbbb-0000-cccc-1111-dddd222eeee")의 쉼표로 구분된 목록으로 구성하여 들어오는 토큰이 클레임에 지정된 tid 대로 지정된 테넌트 중 하나에서 가져오도록 할 수 있습니다. 들어오는 토큰에 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에서 네이티브 클라이언트 또는 디먼 앱을 등록하는 방법을 설명합니다. 사용자를 인증하기만 하려는 경우에는 이 섹션의 단계를 완료하지 않아도 됩니다.

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

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

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

  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 앱에 대해 만든 앱 등록을 선택합니다. 앱 등록이 표시되지 않으면 앱 등록에 user_impersonation 범위를 추가했는지 확인합니다.

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

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

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

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

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

Microsoft Graph로 마이그레이션

몇몇 이전 앱은 사용되지 않는 Azure AD Graph에 대한 종속성으로 설정되었을 수도 있습니다. 이러한 앱은 완전히 사용 중지될 예정입니다. 예를 들어 앱 코드가 Azure AD Graph를 호출하여 미들웨어 파이프라인에서 권한 부여 필터의 일부로 그룹 구성원 자격을 확인했을 수 있습니다. Azure AD Graph 사용 중단 프로세스의 일부로 Microsoft Entra에서 제공하는 지침에 따라 앱을 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에서 제공하는 지침에 따라 업데이트해야 합니다.

다음 단계