Azure App Service와 Azure Functions의 인증 및 권한 부여

Azure App Service는 기본 제공 인증(사용자 로그인) 및 권한 부여(보안 데이터에 대한 액세스 제공) 기능을 제공합니다. 이러한 기능을 간편한 인증이라고도 합니다. 웹앱, RESTful API, 모바일 서버 및 함수에서 코드를 거의 또는 전혀 작성하지 않고 사용자를 로그인하고 데이터에 액세스하는 데 사용할 수 있습니다.

이 문서는 App Service가 앱의 인증 및 권한 부여를 단순화하는 방법에 대해 설명합니다.

기본 제공 인증을 사용하는 이유

인증 및 권한 부여를 구현하기 위해 선택한 웹 프레임워크에서 번들 보안 기능을 사용하거나 고유한 도구를 작성할 수 있습니다. 인증 및 권한 부여를 위한 보안 솔루션을 구현하는 데는 상당한 노력이 소요됩니다. 업계 모범 사례 및 표준을 따라야 합니다. 또한 솔루션이 최신 보안, 프로토콜 및 브라우저 업데이트를 사용하여 최신 상태로 유지되도록 해야 합니다.

App Service 및 Azure Functions의 기본 제공 기능은 페더레이션 ID 공급자를 사용하여 기본 제공 인증을 제공하여 시간과 노력을 절약할 수 있으므로 애플리케이션의 나머지 부분에 집중할 수 있습니다.

App Service를 사용하면 직접 구현하지 않고도 인증 기능을 웹앱 또는 API에 통합할 수 있습니다. 이 기능은 플랫폼에 직접 빌드되며 특정 언어, SDK, 보안 전문 지식 또는 코드가 필요하지 않습니다. Microsoft Entra, Facebook, Google 및 X와 같은 여러 로그인 공급자와 통합할 수 있습니다.

앱은 Visual Studio 통합 또는 증분 동의와 같은 더 복잡한 시나리오를 지원해야 할 수 있습니다. 이러한 시나리오를 지원하기 위해 몇 가지 인증 솔루션을 사용할 수 있습니다. 자세한 내용은 인증 시나리오 및 권장 사항을 참조하세요.

ID 공급자

App Service는 페더레이션 ID를 사용합니다. Microsoft 또는 타사 ID 공급자는 사용자 ID 및 인증 흐름을 관리합니다. 기본적으로 다음 5가지 ID 공급자를 사용할 수 있습니다.

공급자	로그인 엔드포인트	사용 안내서
Microsoft Entra	/.auth/login/aad	App Service Microsoft Entra 플랫폼 로그인
Facebook	/.auth/login/facebook	App Service Facebook 로그인
구글	/.auth/login/google	App Service Google 로그인
X	/.auth/login/x	App Service X 로그인
깃허브	/.auth/login/github	App Service GitHub 로그인
애플	/.auth/login/apple	Apple 로그인을 통한 App Service 로그인(미리 보기)
임의 OpenID Connect 공급자	/.auth/login/<providerName>	App Service OpenID Connect 로그인

이러한 공급자 중 하나를 사용하여 이 기능을 구성하면 해당 로그인 엔드포인트를 사용자 인증 및 공급자의 인증 토큰 유효성 검사에 사용할 수 있습니다. 사용자에게 여러 로그인 옵션을 제공할 수 있습니다.

기본 제공 인증 사용 관련 고려 사항

기본 제공 인증을 사용하도록 설정하면 App Service 구성 설정에 관계없이 HTTPS를 적용하는 애플리케이션에 대한 모든 요청이 자동으로 HTTPS로 리디렉션됩니다. V2 구성의 requireHttps 설정을 사용하여 자동 리디렉션을 비활성화할 수 있습니다. 그러나 HTTPS를 계속 사용하고 보안되지 않은 HTTP 연결을 통해 보안 토큰이 전송되지 않도록 하는 것이 좋습니다.

사이트 콘텐츠 및 API에 대한 액세스를 제한하거나 제한하지 않고 App Service를 인증에 사용할 수 있습니다. 웹앱의 설정>인증 인증>설정 섹션에서 액세스 제한을 설정합니다.

• 앱 액세스를 인증된 사용자로만 제한하려면 구성된 ID 공급자 중 하나로 로그인 하도록 요청이 인증되지 않은 경우 수행할 작업을 설정합니다.
• 액세스를 인증하지만 제한하지 않려면 익명 요청을 허용하도록 요청이 인증되지 않은 경우 수행할작업을 설정합니다(작업 없음).

중요한

각 앱 등록에 고유한 권한 및 동의를 제공해야 합니다. 환경 간에 권한을 공유하는 일이 없도록 배포 슬롯마다 별도의 앱 등록을 사용합니다. 새 코드를 테스트할 때 이 방법을 사용하면 문제가 프로덕션 앱에 영향을 주지 않도록 방지할 수 있습니다.

작동 방식

기능 아키텍처

인증 및 권한 부여 미들웨어 구성 요소는 애플리케이션과 동일한 가상 머신에서 실행되는 플랫폼의 기능입니다. 사용하도록 설정하면 들어오는 모든 HTTP 요청이 해당 구성 요소를 통과한 후 애플리케이션에서 처리합니다.

플랫폼 미들웨어는 다음과 같은 앱의 여러 작업을 처리합니다.

• 지정된 ID 공급자를 사용하여 사용자와 클라이언트를 인증합니다.
• 구성된 ID 공급자가 발급한 OAuth 토큰의 유효성을 검사, 저장 및 새로 고칩니다.
• 인증된 세션 관리
• HTTP 요청 헤더에 ID 정보 삽입

모듈은 애플리케이션 코드와 별도로 실행됩니다. Azure Resource Manager 설정을 사용하거나 구성 파일을 사용하여 구성할 수 있습니다. SDK, 특정 프로그래밍 언어 또는 애플리케이션 코드의 변경이 필요하지 않습니다.

Windows의 기능 아키텍처(컨테이너가 아닌 배포)

인증 및 권한 부여 모듈은 애플리케이션 코드와 동일한 샌드박스에서 네이티브 IIS 모듈 로 실행됩니다. 이를 사용하도록 설정하면 들어오는 모든 HTTP 요청이 이를 통과한 후 애플리케이션이 이를 처리합니다.

Linux 및 컨테이너의 기능 아키텍처

인증 및 권한 부여 모듈은 애플리케이션 코드와 격리된 별도의 컨테이너에서 실행됩니다. 이 모듈은 앰배서더 패턴을 사용하여 들어오는 트래픽과 상호 작용하여 Windows와 유사한 기능을 수행합니다. 프로세스에서 실행되지 않으므로 특정 언어 프레임워크와 직접 통합할 수 없습니다. 그러나 앱에 필요한 관련 정보는 요청 헤더에서 전달됩니다.

인증 흐름

인증 흐름은 모든 공급자에 대해 동일합니다. 공급자의 SDK로 로그인할지 여부에 따라 다릅니다.

• 공급자 SDK가 없는 경우: 애플리케이션은 App Service에 페더레이션된 로그인을 위임합니다. 이 위임은 일반적으로 브라우저 앱의 경우 공급자의 로그인 페이지를 사용자에게 표시할 수 있습니다. 서버 코드는 로그인 프로세스를 관리하므로 서버 지향 흐름 또는 서버 흐름이라고도 합니다.

  이 사례는 인증을 위해 포함된 브라우저를 사용하는 브라우저 앱 및 모바일 앱에 적용됩니다.

• 공급자 SDK를 사용하여: 애플리케이션은 사용자를 공급자에 수동으로 로그인합니다. 그런 다음 유효성 검사를 위해 인증 토큰을 App Service에 제출합니다. 이 프로세스는 일반적으로 브라우저 없는 앱의 경우 공급자의 로그인 페이지를 사용자에게 표시할 수 없습니다. 애플리케이션 코드는 로그인 프로세스를 관리하므로 클라이언트 지향 흐름 또는 클라이언트 흐름이라고도 합니다.

  이 사례는 로그인 프로세스에서 더 많은 유연성이 필요한 브라우저 앱 외에도 REST API, Azure Functions 및 JavaScript 브라우저 클라이언트에 적용됩니다. 공급자의 SDK를 사용하여 사용자를 로그인하는 네이티브 모바일 앱에도 적용됩니다.

App Service의 신뢰할 수 있는 브라우저 앱에서 App Service 또는 Azure Functions 의 다른 REST API로의 호출은 서버 지향 흐름을 통해 인증할 수 있습니다. 자세한 내용은 Azure App Service 인증에서 로그인 및 로그아웃 사용자 지정을 참조하세요.

다음 표는 인증 흐름 단계를 보여 줍니다.

단계	SDK 공급자가 없는 경우	SDK 공급자가 있는 경우
1. 사용자 로그인	공급자는 클라이언트 /.auth/login/<provider>를 .로 리디렉션합니다.	클라이언트 코드는 공급자의 SDK를 사용하여 사용자에게 직접 로그인하고 인증 토큰을 받습니다. 자세한 내용은 공급자의 설명서를 참조하세요.
2. 사후 인증 수행	공급자는 클라이언트 /.auth/login/<provider>/callback를 .로 리디렉션합니다.	클라이언트 코드는 유효성 검사를 위해 공급자의 토큰 을 /.auth/login/<provider> 게시합니다.
3. 인증된 세션 설정	App Service는 응답에 인증된 쿠키를 추가합니다.	App Service는 자체 인증 토큰을 클라이언트 코드에 반환합니다.
4. 인증된 콘텐츠 제공	클라이언트는 후속 요청에 인증 쿠키를 포함합니다(브라우저에서 자동으로 처리됨).	클라이언트 코드는 헤더에 인증 토큰을 X-ZUMO-AUTH 제공합니다.

클라이언트 브라우저의 경우 App Service는 인증되지 않은 모든 사용자를 자동으로 /.auth/login/<provider>로 보냅니다. 선택한 공급자를 사용하여 앱에 로그인할 수 있는 링크를 하나 이상 /.auth/login/<provider> 사용자에게 표시할 수도 있습니다.

권한 부여 동작

Azure Portal에서 들어오는 요청이 인증되지 않은 경우 다양한 동작으로 App Service를 구성할 수 있습니다. 다음 섹션에서는 옵션에 대해 설명합니다.

중요한

기본적으로 이 기능은 인증만 제공하고 권한 부여는 제공하지 않습니다. 애플리케이션은 여기에서 구성하는 검사 외에도 권한 부여를 결정해야 할 수 있습니다.

제한된 액세스

• 인증되지 않은 요청 허용: 이 옵션은 애플리케이션 코드에 대한 인증되지 않은 트래픽의 권한 부여를 연기합니다. 인증된 요청의 경우 App Service는 HTTP 헤더의 인증 정보도 전달합니다.

  이 옵션은 익명 요청을 보다 유연하게 처리할 수 있습니다. 예를 들어 여러 로그인 공급자를 사용자에게 제공할 수 있습니다. 그러나 코드를 작성해야 합니다.

• 인증 필요: 이 옵션은 애플리케이션에 대한 인증되지 않은 트래픽을 거부합니다. 수행할 특정 작업은 이 문서의 뒷부분에 있는 인증되지 않은 요청 섹션에 지정됩니다.

  이 옵션을 사용하면 앱에서 인증 코드를 작성할 필요가 없습니다. 사용자의 클레임을 검사하여 역할별 권한 부여와 같은 더 세부적인 권한 부여를 처리할 수 있습니다.

  주의

  이러한 방식으로 액세스를 제한하면 모든 앱 호출에 제한이 적용되며, 여러 단일 페이지 애플리케이션이 그렇듯이 공개적으로 사용 가능한 홈페이지를 계획하는 앱에는 이 방법이 바람직하지 않을 수 있습니다. 예외가 필요한 경우 구성 파일에서 제외된 경로를 구성해야 합니다.

  참고

  조직의 사용자에 대해 Microsoft ID 공급자를 사용하는 경우 기본 동작은 Microsoft Entra 테넌트의 모든 사용자가 응용 프로그램에 대한 토큰을 요청할 수 있다는 것입니다. 앱에 대한 액세스를 정의된 사용자 집합으로 제한하려는 경우 Microsoft Entra에서 애플리케이션을 구성할 수 있습니다. App Service는 일부 유효성 검사에 도움이 될 수 있는 몇 가지 기본 제공 권한 부여 검사를 제공합니다. Microsoft Entra 권한 부여에 대해 자세히 알아보려면 Microsoft Entra 권한 부여 기본 사항을 참조하세요.

조직의 사용자에 대해 Microsoft ID 공급자를 사용하는 경우 기본 동작은 Microsoft Entra 테넌트의 모든 사용자가 애플리케이션에 대한 토큰을 요청할 수 있다는 것입니다. 앱에 대한 액세스를 정의된 사용자 집합으로 제한하려는 경우 Microsoft Entra에서 애플리케이션을 구성할 수 있습니다. App Service는 일부 유효성 검사에 도움이 될 수 있는 몇 가지 기본 제공 권한 부여 검사 도 제공합니다. Microsoft Entra 권한 부여에 대해 자세히 알아보려면 Microsoft Entra 권한 부여 기본 사항을 참조하세요.

인증되지 않은 요청

• HTTP 302 리디렉션 찾음: 웹 사이트에 권장됨: 구성된 ID 공급자 중 하나로 작업을 리디렉션합니다. 이러한 경우, 선택한 공급자에 대해 브라우저 클라이언트가 /.auth/login/<provider>로 리디렉션됩니다.
• HTTP 401 권한 없음: API에 권장: 익명 요청이 네이티브 모바일 앱에서 가져온 경우 응답을 반환 HTTP 401 Unauthorized 합니다. 모든 요청에 대해 거부를 구성하도록 HTTP 401 Unauthorized 구성할 수도 있습니다.
• HTTP 403 금지됨: 모든 요청에 대한 거부 구성을 설정합니다.
• HTTP 404 찾을 수 없음 모든 요청에 대해 거부가 HTTP 404 Not found가 되도록 구성합니다.

토큰 저장소

App Service는 기본 제공 토큰 저장소를 제공합니다. 토큰 저장소는 웹앱, API 또는 네이티브 모바일 앱의 사용자와 연결된 토큰의 리포지토리입니다. 공급자와 인증을 사용하도록 설정하면 이 토큰 저장소를 앱에서 즉시 사용할 수 있습니다.

애플리케이션 코드가 사용자를 대신하여 이러한 공급자의 데이터에 액세스해야 하는 경우 일반적으로 애플리케이션에서 이러한 토큰을 수집, 저장 및 새로 고치는 코드를 작성해야 합니다. 작업에는 다음이 포함될 수 있습니다.

• 인증된 사용자의 Facebook 타임라인에 게시합니다.
• Microsoft Graph API를 사용하여 사용자의 회사 데이터를 읽습니다.

토큰 저장소를 사용하면 토큰이 필요할 때 토큰을 가져오고 토큰이 무효화되면 App Service에 알려 이를 새로 고치도록 해야 합니다.

ID 토큰, 액세스 토큰 및 새로 고침 토큰은 인증된 세션에 대해 캐시됩니다. 연결된 사용자만 액세스할 수 있습니다.

앱에서 토큰을 사용할 필요가 없는 경우 앱의 설정>인증 페이지에서 토큰 저장소를 사용하지 않도록 설정할 수 있습니다.

로깅 및 추적

애플리케이션 로깅을 사용하도록 설정하면 인증 및 권한 부여 추적이 로그 파일에 직접 표시됩니다. 예상치 못한 인증 오류가 표시되면 기존 애플리케이션 로그를 보고 모든 세부 정보를 편리하게 찾을 수 있습니다.

실패한 요청 추적을 사용하도록 설정하면 인증 및 권한 부여 모듈이 실패한 요청에서 수행할 수 있는 역할을 정확하게 확인할 수 있습니다. 추적 로그에서 EasyAuthModule_32/64라는 모듈에 대한 참조를 찾습니다.

사이트 간 요청 위조 완화

App Service 인증은 다음 조건에 대한 클라이언트 요청을 검사하여 사이트 간 요청 위조를 완화합니다.

• 세션 쿠키를 POST 통해 인증된 요청입니다.
• 요청은 HTTP User-Agent 헤더에 의해 결정된 알려진 브라우저에서 나왔습니다.
• HTTP Origin 또는 HTTP Referer 헤더가 없거나 리디렉션을 위해 승인된 외부 도메인의 구성된 목록에 없습니다.
• HTTP Origin 헤더가 없거나 구성된 CORS(원본 간 리소스 공유) 원본 목록에 없습니다.

요청이 이러한 모든 조건을 충족하면 App Service 인증에서 자동으로 거부합니다. 설정>인증>인증 편집 인증 설정>허용 외부 리디렉션 URL의 리디렉션 목록에 외부 도메인을 추가하여 이 완화 논리를 해결할 수 있습니다.

Azure Front Door 사용에 대한 고려 사항

Azure Front Door 또는 기타 역방향 프록시 뒤에 인증을 사용하여 Azure App Service를 사용하는 경우 다음 작업을 고려합니다.

Azure Front Door 캐싱 사용 안 함

인증 워크플로에 대해 Azure Front Door 캐싱 을 사용하지 않도록 설정합니다.

리디렉션에 Azure Front Door 엔드포인트 사용

App Service는 일반적으로 Azure Front Door에서 노출될 때 직접 액세스할 수 없습니다. 예를 들어 Azure Front Door Premium에서 Azure Private Link를 사용하여 App Service를 노출하여 이 동작을 방지할 수 있습니다. 인증 워크플로가 트래픽을 App Service로 직접 리디렉션하지 못하도록 합니다. 자세한 내용은 리디렉션 URI를 참조하세요.

App Service가 올바른 리디렉션 URI를 사용하고 있는지 확인

일부 구성에서 App Service는 Azure Front Door FQDN 대신 FQDN(정규화된 도메인 이름)을 리디렉션 URI로 사용합니다. 이 구성은 클라이언트가 Azure Front Door 대신 App Service로 리디렉션될 때 문제를 발생합니다. 변경하려면 forwardProxy를 Standard로 설정하여 App Service가 Azure Front Door에서 설정한 X-Forwarded-Host 헤더를 준수하도록 합니다.

Azure Application Gateway 또는 타사 제품과 같은 다른 역방향 프록시는 다른 헤더를 사용하고 다른 forwardProxy 설정이 필요할 수 있습니다.

Azure Portal을 사용하여 구성을 forwardProxy 변경할 수 없습니다. az rest를 사용해야 합니다.

설정 내보내기

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

업데이트 설정

검색 대상:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

convention이(가) Azure Front Door에서 사용하는 Standard 헤더를 준수하도록 X-Forwarded-Host로 설정되어 있는지 확인합니다.

설정 가져오기

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

관련 콘텐츠

App Service 인증에 대한 자세한 내용은 다음을 참조하세요.

• Microsoft Entra 로그인을 사용하도록 App Service 또는 Azure Functions 앱 구성
• Azure 앱 Service 인증에서 로그인 및 로그아웃 사용자 지정
• Azure 앱 Service 인증에서 OAuth 토큰 사용
• Azure App Service 인증에서 사용자 ID 작업
• Azure App Service 인증의 파일 기반 구성

샘플을 보려면 다음을 참조하세요.

• 빠른 시작: Azure App Service에서 실행되는 웹앱에 앱 인증 추가
• 자습서: Azure App Service에서 사용자 전체 인증 및 권한 부여하기
• Azure AppService Easy Auth의 .NET Core 통합 (Microsoft GitHub가 아닌 콘텐츠)
• .NET Core에서 작동하는 Azure App Service 인증 가져오기 (타사 GitHub 콘텐츠)