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

참고 항목

2024년 6월 1일부터, 새로 만들어진 모든 App Service 앱에는 명명 규칙 <app-name>-<random-hash>.<region>.azurewebsites.net을 사용하여 고유한 기본 호스트 이름을 생성할 수 있는 옵션이 제공됩니다. 기존 앱 이름은 변경되지 않은 상태로 유지됩니다.

예: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

자세한 내용은 App Service 리소스의 고유 기본 호스트 이름을 참조하세요.

Azure App Service는 내장된 인증 및 권한 부여 기능(“간편한 인증”이라고 하기도 함)을 제공하므로 웹앱, RESTful API, 모바일 백 엔드에 코드를 최소한으로 작성하거나 코드를 작성하지 않고 사용자를 로그인시켜 데이터에 액세스할 수 있으며 Azure Functions도 사용할 수 있습니다. 이 문서는 App Service가 앱의 인증 및 권한 부여를 단순화하는 방법에 대해 설명합니다.

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

인증 및 권한 부여를 위해 이 기능을 사용할 필요가 없습니다. 선택한 웹 프레임워크에서 번들로 제공되는 보안 기능을 사용하거나 사용자 고유의 유틸리티를 작성할 수 있습니다. 그러나 최신 보안, 프로토콜, 브라우저 업데이트를 사용하여 솔루션이 최신 상태를 유지하는지 확인해야 합니다.

인증(로그인 사용자) 및 권한 부여(보안 데이터에 대한 액세스 제공)용 보안 솔루션을 구현하려면 상당한 노력이 필요할 수 있습니다. 업계 모범 사례와 표준을 따르고 구현을 최신 상태로 유지해야 합니다. App Service 및 Azure Functions을 위한 기본 제공 인증 기능은 페더레이션 ID 공급자를 통해 기본 인증을 제공하여 시간과 노력을 절감할 수 있으므로 애플리케이션의 나머지 부분에 집중할 수 있습니다.

• Azure App Service를 사용하여 다양한 인증 기능을 직접 구현하지 않고도 웹앱 또는 API에 통합할 수 있습니다.
• 플랫폼에 직접 빌드되고 특정 언어, SDK, 보안 기술 또는 코드를 사용할 필요가 없습니다.
• 여러 로그인 공급자와 통합할 수 있습니다. 예를 들어 Microsoft Entra, Facebook, Google, X입니다.

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

ID 공급자

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

공급자	로그인 엔드포인트	방법 가이드
Microsoft Entra	/.auth/login/aad	App Service Microsoft Entra 플랫폼 로그인
Facebook	/.auth/login/facebook	App Service Facebook 로그인
Google	/.auth/login/google	App Service Google 로그인
X	/.auth/login/x	App Service X 로그인
GitHub	/.auth/login/github	App Service GitHub 로그인
Apple로 로그인	/.auth/login/apple	Apple 로그인으로 App Service 로그인(미리 보기)
임의 OpenID Connect 공급자	/.auth/login/<providerName>	App Service OpenID Connect 로그인

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

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

이 기능을 사용하도록 설정하면 HTTPS를 적용하는 App Service 구성 설정에 관계없이 애플리케이션 관련 요청이 모두 HTTPS로 자동 리디렉션됩니다. V2 구성의 requireHttps 설정으로 해당 기능을 사용하지 않게 설정할 수 있습니다. 그러나 HTTPS를 사용하는 것이 좋지만 보안되지 않은 HTTP 연결을 통해 전송되는 보안 토큰이 없어야 합니다.

사이트 콘텐츠 및 API에 대한 액세스를 제한하거나 제한하지 않고 인증을 위해 App Service를 사용할 수 있습니다. 웹앱의 인증>인증 설정 섹션에서 액세스 제한을 설정할 수 있습니다. 앱 액세스를 인증된 사용자로만 제한하려면 요청이 인증되지 않은 경우 수행할 작업을 구성된 ID 공급자 중 하나로 로그인하도록 설정합니다. 액세스를 인증하지만 제한하지 않으려면 요청이 인증되지 않은 경우 수행할 작업을 "익명 요청 허용(작업 없음)"으로 설정합니다.

Important

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

작동 방식

기능 아키텍처

인증 흐름

권한 부여 동작

토큰 저장소

로깅 및 추적

기능 아키텍처

인증 및 권한 부여 미들웨어 구성 요소는 애플리케이션과 동일한 VM에서 실행되는 플랫폼의 기능입니다. 이 기능이 활성화되면 애플리케이션에서 처리되기 전에 들어오는 모든 HTTP 요청이 여기를 통과합니다.

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

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

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

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

인증 및 권한 부여 모듈은 애플리케이션 코드와 동일한 샌드박스에서 네이티브 IIS 모듈 로 실행됩니다. 이 기능이 활성화되면 애플리케이션에서 처리되기 전에 들어오는 모든 HTTP 요청이 여기를 통과합니다.

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

인증 및 권한 부여 모듈은 애플리케이션 코드와 분리된 별도의 컨테이너에서 실행됩니다. 특사 패턴으로 알려진 기능을 사용하면 들어오는 트래픽과 상호 작용하여 Windows에서와 비슷한 기능을 수행할 수 있습니다. In Process로 실행되지 않으므로 특정 언어 프레임워크와의 직접 통합이 가능하지 않습니다. 그러나 앱에 필요한 관련 정보는 아래에 설명된 대로 요청 헤더를 사용하여 전달됩니다.

인증 흐름

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

• 공급자 SDK가 없는 경우: 애플리케이션은 페드레이션 로그인을 App Service에 위임합니다. 이는 일반적으로 공급자의 로그인 페이지를 사용자에게 제공할 수 있는 브라우저 앱을 사용하는 경우입니다. 서버 코드는 로그인 프로세스를 관리하므로 서버 방향 흐름 또는 서버 흐름이라고도 합니다. 이 사례는 인증을 위해 포함된 브라우저를 사용하는 브라우저 앱 및 모바일 앱에 적용됩니다.
• 공급자 SDK 사용: 애플리케이션은 사용자를 수동으로 공급자에 로그인시킨 다음, 유효성 검사를 위해 인증 토큰을 App Service에 제출합니다. 이는 일반적으로 공급자의 로그인 페이지를 사용자에게 제공할 수 없는 브라우저리스 앱을 사용하는 경우입니다. 애플리케이션 코드는 로그인 프로세스를 관리하므로 클라이언트 방향 흐름 또는 클라이언트 흐름이라고도 합니다. 이러한 경우는 REST API, Azure Functions 및 JavaScript 브라우저 클라이언트뿐만 아니라 로그인 프로세스에서 더 많은 유연성이 필요한 브라우저 앱에도 적용됩니다. 공급자의 SDK를 사용하여 사용자를 로그인시키는 네이티브 모바일 앱에도 적용됩니다.

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

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

단계	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> 링크를 사용자에게 할 수도 있습니다.

권한 부여 동작

Important

기본적으로 이 기능은 권한 부여가 아닌 인증만 제공합니다. 여기에서 구성한 모든 검사 외에도 애플리케이션은 여전히 권한 부여 결정을 내려야 할 수 있습니다.

Azure Portal에서 들어오는 요청이 인증되지 않았을 때 여러 동작을 통해 App Service 인증을 구성할 수 있습니다. 다음 제목은 옵션을 설명합니다.

액세스 제한

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

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

• 인증 필요 이 옵션은 애플리케이션에 대한 인증되지 않은 트래픽을 거부합니다. 수행할 구체적인 작업은 인증되지 않은 요청 섹션에 지정되어 있습니다.

  이 옵션을 사용하면 앱에서 인증 코드를 작성할 필요가 없습니다. 역할별 권한 부여와 같이 보다 정교한 권한 부여는 사용자의 클레임을 검사하여 처리할 수 있습니다(사용자 클레임 액세스 참조).

  주의

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

  참고 항목

  조직의 사용자에 대해 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 403 Forbidden이 되도록 구성합니다.
• HTTP 404 찾을 수 없음 모든 요청에 대해 거부가 HTTP 404 Not found가 되도록 구성합니다.

토큰 저장소

App Service는 웹앱, API 또는 기본 모바일 앱의 사용자와 연결된 토큰 리포지토리인 내장 토큰 저장소를 제공합니다. 공급자와 인증을 사용하도록 설정하면 이 토큰 저장소를 앱에서 즉시 사용할 수 있습니다. 다음과 같이 애플리케이션 코드가 사용자를 대신하여 이러한 공급자의 데이터에 액세스해야 하는 경우,

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

일반적으로 애플리케이션에서 이러한 토큰을 수집, 저장 및 새로 고치는 코드를 작성해야 합니다. 토큰 저장소를 사용하면 토큰이 필요할 때 토큰을 가져오고 토큰이 무효화되면 App Service에 알려 이를 새로 고치도록 해야 합니다.

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

앱에서 토큰을 사용할 필요가 없는 경우 앱의 인증/권한 부여 페이지에서 토큰 스토리지를 사용하지 않도록 설정할 수 있습니다.

로깅 및 추적

애플리케이션 로깅을 사용하도록 설정하면 로그 파일에서 인증 및 권한 추적을 바로 볼 수 있습니다. 예상치 못한 인증 오류가 표시되면 기존 애플리케이션 로그를 보고 모든 세부 정보를 편리하게 찾을 수 있습니다. 실패한 요청 추적을 사용하면 실패한 요청에서 인증 및 권한 부여 모듈이 수행한 역할을 정확히 볼 수 있습니다. 추적 로그에서 EasyAuthModule_32/64라는 모듈에 대한 참조를 찾습니다.

교차 사이트 요청 위조 완화

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

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

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

Azure Front Door 사용 시 고려 사항

Azure Front Door 또는 기타 역방향 프록시 뒤에 있는 인증으로 Azure 앱 Service를 사용하는 경우 몇 가지 추가 사항을 고려해야 합니다.

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

• 리디렉션에 Front Door 엔드포인트를 사용합니다.

  App Service는 일반적으로 Azure Front Door를 통해 노출될 때 직접 액세스할 수 없습니다. 이를 방지하는 방법의 한 예는 Azure Front Door 프리미엄에서 Private Link를 통해 App Service를 노출하는 것입니다. 트래픽을 다시 App Service로 직접 리디렉션하는 인증 워크플로를 방지하려면 https://<front-door-endpoint>/.auth/login/<provider>/callback으로 다시 리디렉션하도록 애플리케이션을 구성하는 것이 중요합니다.

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

  일부 구성에서 App Service는 Front Door FQDN 대신 App Service FQDN을 리디렉션 URI로 사용하고 있습니다. 이로 인해 클라이언트가 Front Door 대신 App Service로 리디렉션되는 경우 문제가 발생합니다. 이를 변경하려면 App Service가 Azure Front Door에서 설정한 X-Forwarded-Host 헤더를 준수하도록 forwardProxy 설정을 Standard로 설정해야 합니다.

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

  이 구성은 현재 Azure Portal을 통해 수행할 수 없으며 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"
    }
  }
  

  Azure Front Door에서 사용하는 X-Forwarded-Host 헤더를 존중하도록 convention이 Standard로 설정되었는지 확인합니다.

  설정 가져오기

  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

추가 리소스

• 방법: Microsoft Entra 로그인을 사용하도록 App Service 또는 Azure Functions 앱 구성
• 로그인 및 로그아웃 사용자 지정

• OAuth 토큰 및 세션 작업
• 사용자 및 애플리케이션 클레임에 액세스
• 파일 기반 구성

샘플:

• 자습서: Azure App Service에서 실행되는 웹앱에 인증 추가
• 자습서: Azure App Service에서 엔드투엔드 사용자 인증 및 권한 부여(Windows 또는 Linux)
• Azure AppService EasyAuth의 .NET Core 통합(타사)
• .NET Core를 사용하여 Azure App Service 인증 가져오기(타사)