App Service의 인증 및 권한 부여 살펴보기

• 6분

Azure App Service는 기본 제공 인증 및 권한 부여를 지원합니다. 웹앱, RESTful API, 모바일 백 엔드 또는 Azure Functions에서 최소 코드만 작성하거나 전혀 코드를 작성하지 않고도 사용자를 로그인시키고 데이터에 액세스할 수 있습니다.

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

인증 및 승인을 위해 App Service를 사용할 필요가 없습니다. 많은 웹 프레임워크는 보안 기능과 함께 번들로 제공되며, 필요할 경우 이를 사용할 수 있습니다. App Service가 제공하는 것보다 더 많은 유연성이 필요하면 직접 유틸리티를 작성할 수도 있습니다.

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

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

ID 공급자

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

공급자	로그인 엔드포인트	방법 가이드
Microsoft ID 플랫폼	/.auth/login/aad	App Service Microsoft ID 플랫폼 로그인
Facebook	/.auth/login/facebook	App Service Facebook 로그인
Google	/.auth/login/google	App Service Google 로그인
X	/.auth/login/twitter	App Service X 로그인
임의 OpenID Connect 공급자	/.auth/login/<providerName>	App Service OpenID Connect 로그인
GitHub	/.auth/login/github	App Service GitHub 로그인

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

작동 방식

인증 및 권한 부여 모듈은 애플리케이션 코드와 동일한 샌드박스에서 실행됩니다. 이 기능을 사용하도록 설정하면, 모든 수신 HTTP 요청은 애플리케이션 코드로 전달되기 전에 이를 거칩니다. 이 모듈은 다음과 같이 앱에 대한 몇 가지 사항을 처리합니다.

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

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

인증 흐름

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

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

• 공급자 SDK 사용: 애플리케이션은 사용자를 수동으로 공급자에 로그인시킨 다음, 유효성 검사를 위해 인증 토큰을 App Service에 제출합니다. 이는 일반적으로 공급자의 로그인 페이지를 사용자에게 제공할 수 없는 브라우저리스 앱을 사용하는 경우입니다. 애플리케이션 코드는 로그인 프로세스를 관리하며 클라이언트 방향 흐름 또는 클라이언트 흐름이라고 합니다. 이는 REST API, Azure Functions, JavaScript 브라우저 클라이언트 및 공급자의 SDK를 사용하여 사용자를 로그인하는 네이티브 모바일 앱에 적용됩니다.

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

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

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

권한 부여 동작

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

• 인증되지 않은 요청 허용: 이 옵션은 애플리케이션 코드에 대한 인증되지 않은 트래픽의 권한 부여를 지연시킵니다. 인증된 요청의 경우 App Service는 HTTP 헤더의 인증 정보도 전달합니다. 이 옵션은 익명 요청을 보다 유연하게 처리할 수 있습니다. 여러 로그인 공급자를 사용자에게 제공할 수 있습니다.

• 인증 필요: 이 옵션은 애플리케이션에 대한 인증되지 않은 트래픽을 거부합니다. 이 거부는 구성된 ID 공급자 중 하나에 관한 리디렉션 동작일 수 있습니다. 이 경우 브라우저 클라이언트는 선택한 공급자를 위해 /.auth/login/<provider>로 리디렉션됩니다. 익명의 요청이 네이티브 모바일 앱에서 오는 경우 반환된 응답은 HTTP 401 Unauthorized입니다. 모든 요청에 관해 HTTP 401 Unauthorized 또는 HTTP 403 Forbidden으로 거부를 구성할 수도 있습니다.

  주의

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

토큰 저장소

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

로깅 및 추적

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