Azure App Service 및 Azure Functions의 인증 및 권한 부여Authentication and authorization in Azure App Service and Azure Functions

Azure App Service는 내장된 인증 및 권한 부여 지원을 제공하므로 웹앱, RESTful API 및 모바일 백 엔드에 코드를 최소한으로 작성하거나 코드를 작성하지 않고 사용자를 로그인시켜 데이터에 액세스할 수 있으며 Azure Functions도 사용할 수 있습니다.Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. 이 문서는 App Service가 앱의 인증 및 권한 부여를 단순화하는 방법에 대해 설명합니다.This article describes how App Service helps simplify authentication and authorization for your app.

안전한 인증 및 권한 부여에는 페더레이션, 암호화, JSON 웹 토큰(JWT) 관리, 부여 유형 등 보안에 대한 깊은 이해가 필요합니다.Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and so on. App Service가 이러한 유틸리티를 제공하기 때문에, 고객에게 비즈니스 가치를 제공하는 데 더 많은 시간과 에너지를 투자할 수 있습니다.App Service provides these utilities so that you can spend more time and energy on providing business value to your customer.

중요

인증 및 권한 부여에는이 기능을 사용할 필요가 없습니다.You're not required to use this feature for authentication and authorization. 선택한 웹 프레임 워크에서 번들로 제공 되는 보안 기능을 사용 하거나 사용자 고유의 유틸리티를 작성할 수 있습니다.You can use the bundled security features in your web framework of choice, or you can write your own utilities. 그러나 Chrome 80은 쿠키에 대 한 SameSite 구현에 대 한 주요 변경 내용 (11 월 2020에 출시 된 릴리스 날짜)이 고, 사용자 지정 원격 인증 또는 사이트 간 쿠키 게시를 사용 하는 기타 시나리오는 클라이언트 Chrome 브라우저가 업데이트 될 때 중단 될 수 있다는 점에 유의 하세요.However, keep in mind that Chrome 80 is making breaking changes to its implementation of SameSite for cookies (release date around March 2020), and custom remote authentication or other scenarios that rely on cross-site cookie posting may break when client Chrome browsers are updated. 해결 방법은 다양 한 브라우저에 대해 서로 다른 SameSite 동작을 지원 해야 하기 때문에 복잡 합니다.The workaround is complex because it needs to support different SameSite behaviors for different browsers.

App Service에서 호스팅하는 ASP.NET Core 2.1 이상 버전은이 주요 변경 내용에 대해 이미 패치 되었으며 Chrome 80 및 이전 브라우저를 적절 하 게 처리 합니다.The ASP.NET Core 2.1 and above versions hosted by App Service are already patched for this breaking change and handle Chrome 80 and older browsers appropriately. 또한 ASP.NET Framework 4.7.2에 대 한 동일한 패치가 1 월 2020 전체에 App Service 인스턴스에 배포 되었습니다.In addition, the same patch for ASP.NET Framework 4.7.2 has been deployed on the App Service instances throughout January 2020. 자세한 내용은 Azure App Service SameSite 쿠키 업데이트를 참조 하세요.For more information, see Azure App Service SameSite cookie update.

참고

인증/권한 부여 기능을 "Easy Auth" 라고도 합니다.The Authentication/Authorization feature is also sometimes referred to as "Easy Auth".

참고

이 기능을 사용 하도록 설정 하면 https를 적용하는 App Service 구성 설정에 관계 없이 응용 프로그램에 대 한 모든 비보안 HTTP 요청이 https로 자동으로 리디렉션됩니다.Enabling this feature will cause all non-secure HTTP requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS. 필요한 경우 requireHttps 인증 설정 구성 파일의 설정을 통해이를 사용 하지 않도록 설정할 수 있지만 보안 토큰이 비보안 HTTP 연결을 통해 전송 되지 않도록 주의 해야 합니다.If needed, you can disable this via the requireHttps setting in the auth settings configuration file, but you must then take care to ensure no security tokens ever get transmitted over non-secure HTTP connections.

기본 모바일 응용 프로그램과 관련된 자세한 내용은 Azure App Service를 사용하여 모바일 응용 프로그램에 대한 사용자 인증 및 권한 부여를 참조하세요.For information specific to native mobile apps, see User authentication and authorization for mobile apps with Azure App Service.

작동 방법How it works

WindowsOn Windows

인증 및 권한 부여 모듈은 애플리케이션 코드와 동일한 샌드박스에서 실행됩니다.The authentication and authorization module runs in the same sandbox as your application code. 이 기능이 활성화되면 애플리케이션 코드에 의해 처리되기 전에 들어오는 모든 HTTP 요청이 여기를 통과합니다.When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

배포 된 사이트에 대 한 트래픽을 허용 하기 전에 id 공급자와 상호 작용 하는 사이트 샌드박스에서 프로세스에서 가로채는 요청을 보여 주는 아키텍처 다이어그램

이 모듈은 다음과 같이 앱에 대한 몇 가지 사항을 처리합니다.This module handles several things for your app:

  • 지정된 공급자를 사용하여 사용자 인증Authenticates users with the specified provider
  • 토큰의 유효성 검사, 저장 및 새로 고침Validates, stores, and refreshes tokens
  • 인증된 세션 관리Manages the authenticated session
  • 요청 헤더에 ID 정보 삽입Injects identity information into request headers

모듈은 애플리케이션 코드와 별도로 실행되며 앱 설정을 사용하여 구성됩니다.The module runs separately from your application code and is configured using app settings. SDK, 특정 언어 또는 애플리케이션 코드의 변경이 필요하지 않습니다.No SDKs, specific languages, or changes to your application code are required.

컨테이너에서On Containers

인증 및 권한 부여 모듈은 응용 프로그램 코드와 분리 된 별도의 컨테이너에서 실행 됩니다.The authentication and authorization module runs in a separate container, isolated from your application code. 특사 패턴으로 알려진 기능을 사용 하면 들어오는 트래픽과 상호 작용 하 여 Windows에서와 비슷한 기능을 수행할 수 있습니다.Using what's known as the Ambassador pattern, it interacts with the incoming traffic to perform similar functionality as on Windows. In-process로 실행 되지 않으므로 특정 언어 프레임 워크와의 직접 통합이 가능 하지 않습니다. 그러나 앱에 필요한 관련 정보는 아래에 설명 된 대로 요청 헤더를 사용 하 여 전달 됩니다.Because it does not run in-process, no direct integration with specific language frameworks is possible; however, the relevant information that your app needs is passed through using request headers as explained below.

사용자/응용 프로그램 클레임User/Application claims

모든 언어 프레임 워크에 대해 App Service는 들어오는 토큰의 클레임 (인증 된 최종 사용자 또는 클라이언트 응용 프로그램에서 온 것이 든 관계 없이)을 요청 헤더에 삽입 하 여 코드에서 사용할 수 있도록 합니다.For all language frameworks, App Service makes the claims in the incoming token (whether that be from an authenticated end user or a client application) available to your code by injecting them into the request headers. ASP.NET 4.6 응용 프로그램의 경우 App Service는 인증된 사용자의 클레임을 사용하여 ClaimsPrincipal.Current를 채우기 때문에 [Authorize] 특성을 비롯한 표준 .NET 코드 패턴을 따를 수 있습니다.For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. 마찬가지로 PHP 앱의 경우, App Service는 _SERVER['REMOTE_USER'] 변수를 채웁니다.Similarly, for PHP apps, App Service populates the _SERVER['REMOTE_USER'] variable. Java 앱의 경우 Tomcat 서블릿에서 클레임에 액세스할 수있습니다.For Java apps, the claims are accessible from the Tomcat servlet.

Azure Functions ClaimsPrincipal.Current .net 코드에 대해 채워지지 않지만 요청 헤더에서 사용자 클레임을 찾거나 ClaimsPrincipal 요청 컨텍스트에서 또는 바인딩 매개 변수를 통해 개체를 가져올 수 있습니다.For Azure Functions, ClaimsPrincipal.Current is not populated for .NET code, but you can still find the user claims in the request headers, or get the ClaimsPrincipal object from the request context or even through a binding parameter. 자세한 내용은 클라이언트 id 작업 을 참조 하세요.See working with client identities for more information.

자세한 내용은 사용자 클레임 액세스를 참조하세요.For more information, see Access user claims.

참고

현재 ASP.NET Core는 현재 사용자를 인증/권한 부여 기능으로 채우는 기능을 지원 하지 않습니다.At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature. 그러나 이러한 차이를 해결 하기 위해 일부 타사 오픈 소스 미들웨어 구성 요소가 존재 합니다.However, some 3rd party, open source middleware components do exist to help fill this gap.

토큰 저장소Token store

App Service는 웹앱, API 또는 기본 모바일 앱의 사용자와 연결된 토큰 리포지토리인 내장 토큰 저장소를 제공합니다.App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. 공급자와 인증을 사용하도록 설정하면 이 토큰 저장소를 앱에서 즉시 사용할 수 있습니다.When you enable authentication with any provider, this token store is immediately available to your app. 다음과 같이 애플리케이션 코드가 사용자를 대신하여 이러한 공급자의 데이터에 액세스해야 하는 경우,If your application code needs to access data from these providers on the user's behalf, such as:

  • 인증된 사용자의 Facebook 타임라인에 게시post to the authenticated user's Facebook timeline
  • Microsoft Graph API를 사용 하 여 사용자의 회사 데이터 읽기read the user's corporate data using the Microsoft Graph API

일반적으로 애플리케이션에서 이러한 토큰을 수집, 저장 및 새로 고치는 코드를 작성해야 합니다.You typically must write code to collect, store, and refresh these tokens in your application. 토큰 저장소를 사용하면 토큰이 필요할 때 토큰을 가져오고 토큰이 무효화되면 App Service에 알려 이를 새로 고치도록 해야 합니다.With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

ID 토큰, 액세스 토큰 및 새로 고침 토큰은 인증 된 세션에 대해 캐시 되며 연결 된 사용자만 액세스할 수 있습니다.The ID tokens, access tokens, and refresh tokens are cached for the authenticated session, and they're accessible only by the associated user.

앱에서 토큰을 사용할 필요가 없는 경우 앱의 인증/권한 부여 페이지에서 토큰 저장소를 사용 하지 않도록 설정할 수 있습니다.If you don't need to work with tokens in your app, you can disable the token store in your app's Authentication / Authorization page.

로깅 및 추적Logging and tracing

애플리케이션 로깅을 사용하도록 설정하면 로그 파일에서 인증 및 권한 추적을 바로 볼 수 있습니다.If you enable application logging, you will see authentication and authorization traces directly in your log files. 예상치 못한 인증 오류가 표시 되 면 기존 응용 프로그램 로그를 확인 하 여 모든 세부 정보를 편리 하 게 찾을 수 있습니다.If you see an authentication error that you didn't expect, you can conveniently find all the details by looking in your existing application logs. 실패한 요청 추적을 사용하면 실패한 요청에서 인증 및 권한 부여 모듈이 수행한 역할을 정확히 볼 수 있습니다.If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. 추적 로그에서 EasyAuthModule_32/64라는 모듈에 대한 참조를 찾습니다.In the trace logs, look for references to a module named EasyAuthModule_32/64.

ID 공급자Identity providers

App Service는 페더레이션 ID를 사용하며 여기서 타사 ID 공급자는 사용자 ID와 인증 흐름을 관리합니다.App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. 기본적으로 5가지 ID 공급자를 사용할 수 있습니다.Five identity providers are available by default:

공급자Provider 로그인 엔드포인트Sign-in endpoint
Azure Active DirectoryAzure Active Directory /.auth/login/aad
Microsoft 계정Microsoft Account /.auth/login/microsoftaccount
FacebookFacebook /.auth/login/facebook
GoogleGoogle /.auth/login/google
TwitterTwitter /.auth/login/twitter
모든 Openid connect Connect 공급자 (미리 보기)Any OpenID Connect provider (preview) /.auth/login/<providerName>

이러한 공급자중 하나를 사용하여 인증 및 권한 부여를 활성화하면 사용자 인증과 공급자의 인증 토큰 유효성 검사에 로그인 엔드포인트를 사용할 수 있습니다.When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. 사용자에게 여러 가지 로그인 옵션을 쉽게 제공할 수 있습니다.You can provide your users with any number of these sign-in options with ease.

레거시 확장성 경로 는 다른 id 공급자 또는 사용자 지정 인증 솔루션과 통합 하기 위해 존재 하지만 권장 되지 않습니다.A legacy extensibility path exists for integrating with other identity providers or a custom auth solution, but this is not recommended. 대신 Openid connect Connect 지원 사용을 고려 하십시오.Instead, consider using the OpenID Connect support.

인증 흐름Authentication flow

인증 흐름은 모든 공급자에 대해 동일하지만 공급자의 SDK로 로그인하는지 여부에 따라 다릅니다.The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK:

  • 공급자 SDK가 없는 경우: 애플리케이션은 페드레이션 로그인을 App Service에 위임합니다.Without provider SDK: The application delegates federated sign-in to App Service. 이는 일반적으로 공급자의 로그인 페이지를 사용자에게 제공할 수 있는 브라우저 앱을 사용하는 경우입니다.This is typically the case with browser apps, which can present the provider's login page to the user. 서버 코드는 로그인 프로세스를 관리하므로 서버 방향 흐름 또는 _서버 흐름_이라고도 합니다.The server code manages the sign-in process, so it is also called server-directed flow or server flow. 이 경우는 브라우저 앱에 적용됩니다.This case applies to browser apps. 또한 SDK가 App Service 인증을 사용하여 사용자를 로그인시키기 위해 웹 보기를 열기 때문에 Mobile Apps 클라이언트 SDK를 사용하여 사용자를 로그인시키는 네이티브 앱에도 적용됩니다.It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
  • 공급자 SDK 사용: 애플리케이션은 사용자를 수동으로 공급자에 로그인시킨 다음, 유효성 검사를 위해 인증 토큰을 App Service에 제출합니다.With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. 이는 일반적으로 공급자의 로그인 페이지를 사용자에게 제공할 수 없는 브라우저리스 앱을 사용하는 경우입니다.This is typically the case with browser-less apps, which can't present the provider's sign-in page to the user. 애플리케이션 코드는 로그인 프로세스를 관리하므로 클라이언트 방향 흐름 또는 _클라이언트 흐름_이라고도 합니다.The application code manages the sign-in process, so it is also called client-directed flow or client flow. 이러한 경우는 REST API, Azure Functions 및 JavaScript 브라우저 클라이언트뿐만 아니라 로그인 프로세스에서 더 많은 유연성이 필요한 브라우저 앱에도 적용됩니다.This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. 공급자의 SDK를 사용하여 사용자를 로그인시키는 네이티브 모바일 앱에도 적용됩니다.It also applies to native mobile apps that sign users in using the provider's SDK.

참고

App Service의 신뢰할 수 있는 브라우저 앱에서 App Service 또는 Azure Functions 의 다른 REST API에 대 한 호출은 서버 지향 흐름을 사용 하 여 인증할 수 있습니다.Calls from a trusted browser app in App Service to another REST API in App Service or Azure Functions can be authenticated using the server-directed flow. 자세한 내용은 App Service에서 인증 및 권한 부여 사용자 지정을 참조하세요.For more information, see Customize authentication and authorization in App Service.

아래 표는 인증 흐름 단계를 보여줍니다.The table below shows the steps of the authentication flow.

단계Step SDK 공급자가 없는 경우Without provider SDK SDK 공급자가 있는 경우With provider SDK
1. 사용자 로그인1. Sign user in 클라이언트를 /.auth/login/<provider>로 리디렉션합니다.Redirects client to /.auth/login/<provider>. 클라이언트 코드는 공급자의 SDK를 사용하여 사용자를 직접 로그인시키고 인증 토큰을 받습니다.Client code signs user in directly with provider's SDK and receives an authentication token. 자세한 내용은 공급자 설명서를 참조하세요.For information, see the provider's documentation.
2. 인증 후2. Post-authentication 공급자가 클라이언트를 /.auth/login/<provider>/callback으로 리디렉션합니다.Provider redirects client to /.auth/login/<provider>/callback. 클라이언트 코드는 유효성 검사를 위해 공급자에서로 토큰을 게시 /.auth/login/<provider> 합니다.Client code posts token from provider to /.auth/login/<provider> for validation.
3. 인증 된 세션 설정3. Establish authenticated session App Service는 인증된 쿠키를 응답에 추가합니다.App Service adds authenticated cookie to response. App Service는 자체 인증 토큰을 클라이언트 코드로 반환합니다.App Service returns its own authentication token to client code.
4. 인증 된 콘텐츠 제공4. Serve authenticated content 클라이언트는 후속 요청에 인증 쿠키를 포함합니다(브라우저에 의해 자동 처리됨).Client includes authentication cookie in subsequent requests (automatically handled by browser). 클라이언트 코드는 X-ZUMO-AUTH 헤더에 인증 토큰을 제공합니다(Mobile Apps 클라이언트 SDK에 의해 자동 처리됨).Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

클라이언트 브라우저의 경우 App Service는 인증되지 않은 모든 사용자를 자동으로 /.auth/login/<provider>로 보냅니다.For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. 사용자 자신이 선택한 제공자를 사용하여 앱에 로그인할 수 있도록 하나 이상의 /.auth/login/<provider> 링크를 사용자에게 할 수도 있습니다.You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

권한 부여 동작Authorization behavior

Azure Portal에서 들어오는 요청이 인증 되지 않은 경우 여러 동작을 사용 하 여 App Service 권한 부여를 구성할 수 있습니다.In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated.

"요청이 인증 되지 않은 경우 수행할 작업" 드롭다운을 보여 주는 스크린샷

다음 제목은 옵션을 설명합니다.The following headings describe the options.

익명 요청 허용 (작업 없음)Allow Anonymous requests (no action)

이 옵션은 응용 프로그램 코드에 대 한 인증 되지 않은 트래픽의 권한 부여를 지연 시킵니다.This option defers authorization of unauthenticated traffic to your application code. 인증된 요청의 경우 App Service는 HTTP 헤더의 인증 정보도 전달합니다.For authenticated requests, App Service also passes along authentication information in the HTTP headers.

이 옵션은 익명 요청을 보다 유연하게 처리할 수 있습니다.This option provides more flexibility in handling anonymous requests. 예를 들어 여러 로그인 공급자를 사용자에게 제공할 수 있습니다.For example, it lets you present multiple sign-in providers to your users. 그러나 코드를 작성해야 합니다.However, you must write code.

인증된 요청만 허용Allow only authenticated requests

옵션은 **로 <provider> 로그인 **합니다.The option is Log in with <provider>. App Service는 사용자가 선택한 공급자에 대한 모든 익명 요청을 /.auth/login/<provider>로 리디렉션합니다.App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. 익명의 요청이 네이티브 모바일 앱에서 오는 경우 반환된 응답은 HTTP 401 Unauthorized입니다.If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

이 옵션을 사용하면 앱에서 인증 코드를 작성할 필요가 없습니다.With this option, you don't need to write any authentication code in your app. 역할별 권한 부여와 같이 보다 정교한 권한 부여는 사용자의 클레임을 검사하여 처리할 수 있습니다(사용자 클레임 액세스 참조).Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims).

주의

이러한 방식으로 액세스를 제한 하는 것은 앱에 대 한 모든 호출에 적용 됩니다 .이는 여러 단일 페이지 응용 프로그램과 마찬가지로 공개적으로 사용 가능한 홈 페이지를 사용 하는 앱에는 바람직하지 않을 수 있습니다.Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.

추가 리소스More resources

공급자별 방법 가이드:Provider-specific how-to guides: