다음을 통해 공유

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

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

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

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

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

  1. Azure Portal에 로그인하고 앱으로 이동합니다.

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

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

  4. 애플리케이션 및 사용자를 위한 테넌트 선택에서 다음 중 하나를 선택합니다.

    • 직원 및 비즈니스 고객을 위한 인력 구성(현재 테넌트)
    • 소비자 및 비즈니스 고객을 위한 외부 구성

앱 등록 선택하기

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

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

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

  • 계정에 Microsoft Entra 테넌트에서 앱 등록을 만들 수 있는 권한이 없습니다.
  • 앱이 포함된 Microsoft Entra 테넌트와 다른 Microsoft Entra 테넌트의 앱 등록을 사용하려고 합니다. 테넌트를 선택할 때 외부 구성을 선택한 경우에는 항상 이 경우가 적용됩니다.
  • 정부 클라우드에서는 새 등록을 만드는 옵션을 사용할 수 없습니다.

옵션 1: 앱 등록을 새로 만들어 사용

  1. 새로운 앱 등록 만들기를 선택합니다.

  2. 이름에 새 앱 등록의 이름을 입력합니다.

  3. 지원되는 계정 유형 값을 선택합니다.

    • 현재 테넌트 - 단일 테넌트. 이 조직 디렉터리의 계정만 해당. 디렉터리의 모든 사용자 및 게스트 계정은 사용자의 애플리케이션 또는 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 참조를 사용할 수 있습니다. 또는 클라이언트 암호 대신 ID를 사용하도록 변경할 수 있습니다. 현재 ID 사용에 대한 지원은 미리 보기 단계에 있습니다.

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

기존 등록을 사용하려면 다음 중 하나를 선택합니다.

  • 이 디렉터리에서 기존 앱 등록을 선택합니다. 그런 다음 드롭다운 목록에서 앱 등록을 선택합니다.

  • 기존 앱 등록의 세부 정보를 제공합니다. 그런 후 다음을 제공합니다.

    • 애플리케이션(클라이언트) ID.

    • 클라이언트 암호(권장). 토큰을 요청할 때 애플리케이션이 자신의 ID를 증명하는 데 사용하는 비밀 값입니다. 이 값은 사용자의 앱 구성에 이름이 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET인 슬롯 고정 애플리케이션 설정으로 저장됩니다. 클라이언트 암호가 설정되지 않은 경우 서비스의 로그인 작업은 OAuth 2.0 암시적 허용 흐름을 사용하지만, 이것은 권장되지 않습니다.

      또한 클라이언트 암호 대신 ID를 사용하도록 애플리케이션을 구성할 수도 있습니다. 현재 ID 사용에 대한 지원은 미리 보기 단계에 있습니다.

    • 발급자 URL. 이 URL은 <authentication-endpoint>/<tenant-id>/v2.0 형식을 따릅니다. <authentication-endpoint>를 클라우드 환경에 특정한 인증 엔드포인트 값으로 바꿉니다. 예를 들어 글로벌 Azure의 인력 테넌트는 https://sts.windows.net을 인증 엔드포인트로 사용합니다.

Workforce 테넌트에서 앱 등록을 수동으로 만들어야 하는 경우 Microsoft ID 플랫폼에 애플리케이션 등록을 참조하세요. 등록 프로세스를 진행하면서 애플리케이션(클라이언트) ID 및 클라이언트 암호 값을 확실히 기록해 둡니다.

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

이제 앱 등록을 수정합니다.

  1. 왼쪽 창에서 API 노출>추가>저장을 선택합니다. 이 값은 리소스로 사용될 때 애플리케이션을 고유하게 식별하여 액세스 권한을 부여하는 토큰을 요청할 수 있습니다. 값은 사용자가 만든 범위에 대한 접두사입니다.

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

  2. 범위 추가를 선택한 다음 다음을 수행합니다.

    1. 범위 이름에 user_impersonation을 입력합니다.
    2. 사용자가 이 범위에 동의하도록 허용하려면 동의할 수 있는 사람에서 관리자 및 사용자를 선택합니다.
    3. 동의 범위 이름을 입력합니다. 동의 페이지에 사용자에게 표시할 설명을 입력합니다. 예를 들어, 액세스application-name을 입력합니다.
    4. 범위 추가를 선택합니다.

  3. (권장) 앱에 대한 클라이언트 어설션을 만듭니다. 클라이언트 암호를 만들려면 다음을 수행합니다.

    1. 왼쪽 창에서 인증서 및 비밀>클라이언트 암호>새 클라이언트 암호를 선택합니다.
    2. 설명과 만료일을 입력한 다음 추가를 선택합니다.
    3. 값 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 다시 나타나지 않습니다.

    또한 클라이언트 암호 대신 ID를 사용하도록 애플리케이션을 구성할 수도 있습니다. 현재 ID 사용에 대한 지원은 미리 보기 단계에 있습니다.

  4. (선택 사항) 회신 URL을 여러 개 추가하려면 인증을 선택합니다.

추가 검사 구성

추가 검사를 통해 어떤 요청이 애플리케이션에 액세스할 수 있는지 결정합니다. 지금 이 동작을 사용자 지정하거나, 나중에 기본 인증 페이지에서 인증 설정 옆에 있는 편집을 선택하여 설정을 조정할 수 있습니다.

클라이언트 애플리케이션 요구 사항에는 다음의 수행 여부를 선택합니다.

  • 이 애플리케이션 자체의 요청만 허용
  • 특정 클라이언트 애플리케이션의 요청 허용
  • 모든 애플리케이션의 요청 허용(권장하지 않음)

ID 요구 사항에는 다음의 수행 여부를 선택합니다.

  • 모든 ID의 요청 허용
  • 특정 ID의 요청 허용

테넌트 요구 사항에는 다음의 수행 여부를 선택합니다.

  • 발급자 테넌트의 요청만 허용
  • 특정 테넌트에서 요청 허용
  • 발급자에 따라 기본 제한을 사용합니다.

앱은 코드에서 다른 권한 부여 결정을 내려야 할 수도 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 기본 제공 권한 부여 정책 사용을 참조하세요.

인증 설정 구성

인증 설정은 애플리케이션이 인증되지 않은 요청에 어떻게 응답하는지 결정합니다. 기본 선택 항목은 모든 요청을 리디렉션하여 이 새 공급자로 로그인합니다. 지금 이 동작을 사용자 지정하거나, 나중에 기본 인증 페이지에서 인증 설정 옆에 있는 편집을 선택하여 설정을 조정할 수 있습니다. 자세한 내용은 인증 흐름을 참조하세요.

액세스 제한에서는 다음의 수행 여부를 결정합니다.

  • 인증 필요
  • 인증되지 않은 액세스 허용

인증되지 않은 요청의 경우 오류 옵션을 선택합니다.

  • HTTP 302 Found redirect: 웹 사이트에 권장됨
  • HTTP 401 Unauthorized: API에 권장됨
  • HTTP(HTTP) 403 Forbidden
  • HTTP(HTTP) 404 Not found

토큰 저장소를 선택합니다(권장됨). 토큰 저장소는 애플리케이션의 토큰을 수집하거나 저장하고 새로 고칩니다. 앱에 토큰이 필요하지 않거나 성능을 최적화해야 하는 경우 나중에 이 동작을 사용하지 않도록 설정할 수 있습니다.

ID 공급자 추가

인력 구성을 선택한 경우 다음: 권한을 선택하고 애플리케이션에 필요한 Microsoft Graph 권한을 추가할 수 있습니다. 이러한 권한은 앱 등록에 추가되지만 나중에 변경할 수도 있습니다. 외부 구성을 선택한 경우 나중에 Microsoft Graph 권한을 추가할 수 있습니다.

  • 추가를 선택합니다.

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

Azure Storage 및 Microsoft Graph에 액세스하는 웹앱에 대한 Microsoft Entra 로그인을 구성하는 예는 웹앱에 앱 인증 추가를 참조하세요.

요청 권한 부여

기본적으로 App Service 인증은 인증만 처리합니다. 이는 발신자가 본인이라고 말하는 사용자인지 여부를 판단합니다. 권한 부여는 발신자가 어떤 리소스에 액세스할 수 있는지 여부를 결정하는 단계로, 인증을 넘어선 단계입니다. 자세한 내용은 권한 부여 기본 사항을 참조하세요.

앱은 코드에서 권한 부여를 결정할 수 있습니다. App Service 인증은 도움이 될 수 있는 몇 가지 기본 제공 검사를 제공하지만, 이것만으로는 앱의 권한 부여 요구 사항을 충족하기에 충분하지 않을 수 있습니다. 다음 섹션에서는 이러한 기능에 대해 설명합니다.

팁

다중 테넌트 애플리케이션은 이 프로세스의 일부로 요청의 발급자와 테넌트 ID의 유효성을 검사하여 값이 허용되는지 유효성을 검사해야 합니다. App Service 인증이 다중 테넌트 시나리오에 맞게 구성된 경우 요청이 어떤 테넌트에서 왔는지 유효성을 검사하지 않습니다. 예를 들어, 조직이 서비스에 가입했는지 여부에 따라 앱을 특정 테넌트로 제한해야 할 수도 있습니다. 여러 발급자 값을 처리하도록 코드 업데이트를 참조하세요.

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

앱 코드에서 권한 부여 검사를 수행하는 경우 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 공급자 구성에는 다음 구조에서 볼 수 있듯이 validation 개체를 포함할 수 있는 defaultAuthorizationPolicy 섹션이 있습니다.

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
속성 설명
defaultAuthorizationPolicy 앱에 액세스하기 위해 충족해야 하는 요구 사항 그룹입니다. 구성된 각 속성에 대한 논리적 AND를 기반으로 액세스 권한이 부여됩니다. allowedApplications와 allowedPrincipals가 모두 구성된 경우 수신 요청은 수락되려면 두 가지 요구 사항을 모두 충족해야 합니다.
allowedApplications 앱을 호출하는 클라이언트 리소스를 나타내는 문자열 애플리케이션 클라이언트 ID의 허용 목록입니다. 이 속성이 비어 있지 않은 배열로 구성된 경우 목록에 지정된 애플리케이션에서 가져오는 토큰만 수락됩니다.

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

이 정책은 수신 토큰의 oid 클레임을 평가합니다. 페이로드 클레임을 참조하세요.

또한 사용 중인 API 버전에 관계없이 애플리케이션 설정을 통해 일부 검사를 구성할 수 있습니다. 최대 10개의 테넌트 ID를 쉼표로 구분하여 목록으로 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 애플리케이션 설정을 구성할 수 있습니다(예: aaaabbbb-0000-cccc-1111-dddd2222eeee). 이 설정에서는 수신 토큰이 tid 클레임에서 지정한 대로 지정된 테넌트 중 하나에서 나와야 할 수 있습니다.

WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL 애플리케이션 설정을 true 또는 1로 구성하여 수신 토큰에 oid 클레임이 포함되도록 요구할 수 있습니다. allowedPrincipals.identities를 구성한 경우 oid 클레임이 제공된 ID 목록과 비교 검사되므로 이 설정은 무시되고 true로 처리됩니다.

이러한 기본 제공 검사에 실패한 요청은 HTTP 403 Forbidden 응답을 가져옵니다.

비밀 대신 관리 ID 사용(미리 보기)

앱 등록을 위해 클라이언트 암호를 구성하는 대신 관리 ID를 신뢰하도록 애플리케이션을 구성(미리 보기)할 수 있습니다. 비밀 대신 ID를 사용하면 비밀을 관리할 필요가 없습니다. 처리해야 할 비밀 만료 이벤트가 없고, 비밀이 공개되거나 유출될 가능성과 관련된 동일한 수준의 위험도 없습니다.

ID를 사용하면 클라이언트 암호 대신 클라이언트 어설션으로 사용할 수 있는 연방 ID 자격 증명을 만들 수 있습니다. 이 방법은 인력 구성에만 사용할 수 있습니다. 기본 제공된 인증 기능은 현재 미리 보기로 페더레이션된 ID 자격 증명을 지원합니다.

이 섹션의 단계를 사용하면 이 패턴을 사용하도록 App Service 또는 Azure Functions 리소스를 구성할 수 있습니다. 여기의 단계에서는 지원되는 방법 중 하나를 사용하여 앱 등록을 이미 설정했고, 비밀이 이미 정의되어 있다고 가정합니다.

  1. 이러한 지침에 따라 사용자 할당 관리 ID 리소스를 만듭니다.

  2. App Service 또는 Azure Functions 리소스에 해당 ID를 할당합니다.

    중요합니다

    사용자가 할당한 관리 ID는 이 등록을 통해서만 App Service 또는 Azure Functions 애플리케이션에 할당되어야 합니다. 다른 리소스에 ID를 할당하면 해당 리소스에 앱 등록에 대한 불필요한 액세스 권한을 부여하는 것입니다.

  3. 관리 ID의 개체 ID 및 클라이언트 ID 값을 기록해 둡니다. 다음 단계에서는 페더레이션된 ID 자격 증명을 만들려면 개체 ID가 필요합니다. 이후 단계에서는 관리 ID의 클라이언트 ID를 사용합니다.

  4. 기존 애플리케이션에서 페더레이션된 ID 자격 증명을 구성하려면 Microsoft Entra ID 지침을 따릅니다. 해당 지침에는 건너뛸 수 있는 애플리케이션 코드 업데이트 섹션도 포함되어 있습니다.

  5. 라는 이름의 새로운 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID을 추가합니다. 이전 단계에서 가져오는 관리 ID의 클라이언트 ID 값으로 값을 설정합니다. 앱 등록 시 클라이언트 ID를 사용하지 마세요. 이 애플리케이션 설정을 슬롯 고정으로 표시해야 합니다.

  6. 앱 리소스에 대한 기본 인증 설정에서 클라이언트 암호 설정 이름을 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID로 설정합니다.

    Azure Portal을 사용하여 이 변경을 수행하려면 다음을 수행합니다.

    1. App Service 또는 Azure Functions 리소스로 돌아가서 인증 탭을 선택합니다.
    2. ID 공급자 섹션에서 Microsoft 엔터티에 대해 편집 열에 있는 아이콘을 선택합니다.
    3. ID 공급자 편집 대화 상자에서 클라이언트 암호 설정 이름에 대한 드롭다운 목록을 열고 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID를 선택합니다.
    4. 저장을 선택합니다.

    REST API를 사용하여 이 변경을 수행하려면 다음을 수행합니다.

    • clientSecretSettingName 속성을 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID으로 설정합니다. properties > identityProviders > azureActiveDirectory > registration에서 이 속성을 찾을 수 있습니다.

  7. 애플리케이션이 예상대로 작동하는지 확인합니다. 새로운 로그인 작업을 성공적으로 수행할 수 있어야 합니다.

관리 ID를 사용하여 동작에 만족하면 기존 비밀을 제거합니다.

  1. 앱 코드가 애플리케이션 설정에 종속되지 않도록 합니다. 그렇다면 액세스 토큰을 요청하기 위해 애플리케이션 코드를 업데이트하는 지침을 따릅니다.

  2. 이전에 비밀을 보관했던 애플리케이션 설정을 제거합니다. 이 애플리케이션 설정의 이름은 로 설정하기 전의 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID 값입니다.

  3. 앱 등록이 포함된 테넌트를 사용하여 Microsoft Entra 관리 센터에 로그인합니다. 앱 등록으로 다시 이동합니다.

  4. 인증서 및 비밀에서 클라이언트 암호를 선택하고 클라이언트 암호를 제거합니다.

이제 앱이 비밀 없이 Microsoft Entra ID 인증을 사용하도록 구성되었습니다.

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

이전 섹션에서는 사용자를 인증하기 위해 App Service 또는 Azure Functions 앱을 등록했습니다. 다음 섹션에서는 Microsoft Entra에서 네이티브 클라이언트나 디먼 앱을 등록하는 방법을 설명합니다. 이러한 클라이언트나 앱은 N계층 아키텍처와 같이 사용자나 자신을 대신하여 App Service에서 노출된 API에 대한 액세스를 요청할 수 있습니다. 사용자 인증만 원하는 경우 다음 섹션의 단계는 필요하지 않습니다.

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

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

  1. Azure Portal 메뉴에서 Microsoft Entra ID를 선택합니다.

  2. 왼쪽 창에서 관리>앱 등록을 선택합니다. 그런 다음 새 등록을 선택합니다.

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

  4. 리디렉션 URI에서 공용 클라이언트/네이티브(모바일 및 데스크톱)를 선택하고 리디렉션 URL을 입력합니다. 예를 들어 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 또는 Azure Functions 앱을 호출하는 토큰을 획득할 수 있습니다. 이 시나리오는 로그인한 사용자가 없는 상태에서 작업을 수행하는 비대화형 디먼 애플리케이션에 유용합니다. 이 파일은 표준 OAuth 2.0 클라이언트 자격 증명 권한 부여를 사용합니다. 자세한 내용은 Microsoft ID 플랫폼 및 OAuth 2.0 클라이언트 자격 증명 흐름을 참조하세요.

  1. Azure Portal 메뉴에서 Microsoft Entra ID를 선택합니다.

  2. 왼쪽 창에서 관리>앱 등록을 선택합니다. 그런 다음 새 등록을 선택합니다.

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

  4. 디먼 애플리케이션의 경우 리디렉션 URI가 필요하지 않으므로 리디렉션 URI 상자를 비워두면 됩니다.

  5. 등록을 선택합니다.

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

  7. 왼쪽 창에서 관리>인증서 및 비밀을 선택합니다. 그런 다음 클라이언트 암호>새 클라이언트 암호를 선택합니다.

  8. 설명과 만료일을 입력한 다음 추가를 선택합니다.

  9. 값 필드에서 클라이언트 암호 값을 복사합니다. 이 페이지에서 벗어나면 다시 나타나지 않습니다.

이제 클라이언트 ID와 클라이언트 암호를 사용하여 액세스 토큰을 요청할 수 있습니다. resource 매개 변수를 대상 앱의 애플리케이션 ID URI 값으로 설정합니다. 생성된 액세스 토큰은 표준 OAuth 2.0 인증 헤더를 통해 대상 앱에 제공될 수 있습니다. App Service 인증은 토큰의 유효성을 검사하고 사용하여 발신자가 인증되었음을 나타냅니다. 이 경우 발신자는 사용자가 아니라 애플리케이션입니다.

이 방식을 사용하면 Microsoft Entra 테넌트의 모든 클라이언트 애플리케이션이 액세스 토큰을 요청하고 대상 앱에 인증할 수 있습니다. 특정 클라이언트 애플리케이션만 허용하도록 권한을 강제로 적용하려는 경우 추가 구성을 수행해야 합니다.

  1. 보호하려는 App Service 또는 Azure Functions 앱을 나타내는 앱 등록 매니페스트에서 앱 역할을 정의합니다.

  2. 권한이 필요한 클라이언트를 나타내는 앱 등록에서 API 권한>권한 추가>내 API를 선택합니다.

  3. 이전에 만든 앱 등록을 선택합니다. 앱 등록이 보이지 않으면 앱 역할을 추가했는지 확인합니다.

  4. 애플리케이션 권한에서 앞서 만든 앱 역할을 선택합니다. 사용 권한 추가를 선택합니다.

  5. 관리자 동의 허용을 선택하여 클라이언트 애플리케이션이 권한을 요청하도록 권한 부여합니다.

    이전 시나리오(역할을 추가하기 전)와 유사하게 이제 동일한 대상 리소스에 대한 액세스 토큰을 요청할 수 있습니다. 액세스 토큰에는 클라이언트 애플리케이션에 대해 권한이 있는 앱 역할이 포함된 roles 클레임이 포함되어 있습니다.

이제 대상 App Service 또는 Azure Functions 앱 코드 내에서 토큰에 예상된 역할이 있는지 유효성을 검사할 수 있습니다. 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 권한을 추가한 후에는 다음을 수행할 수 있습니다.

  • 아직 접미사가 포함되어 있지 않으면 /v2.0 값을 업데이트하여 이를 포함합니다.

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

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

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

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

이러한 변경 내용을 적용하면 App Service 인증에서 로그인을 시도할 때 더 이상 Azure AD Graph에 대한 권한을 요청하지 않습니다. 대신 Microsoft Graph에 대한 토큰을 가져옵니다. Azure AD Graph에서 Microsoft Graph로 앱 마이그레이션에 설명된 대로 애플리케이션 코드에서 해당 토큰을 사용하는 경우에도 업데이트해야 합니다.

관련 콘텐츠