Azure Container Apps의 인증 및 권한 부여

아티클
04/23/2024

Azure Container Apps는 코드를 최소화하거나 사용하지 않고 외부 수신 지원 컨테이너 앱을 보호하기 위해 기본 제공 인증 및 권한 부여 기능("간편한 인증"이라고도 함)을 제공합니다.

인증 및 권한 부여에 대한 자세한 내용은 공급자 선택에 대한 다음 가이드를 참조하세요.

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

인증 및 권한 부여를 위해 이 기능을 사용할 필요가 없습니다. 선택한 웹 프레임워크에서 번들로 제공되는 보안 기능을 사용하거나 사용자 고유의 유틸리티를 작성할 수 있습니다. 그러나 인증(로그인 사용자) 및 권한 부여(보안 데이터에 대한 액세스 제공)용 보안 솔루션을 구현하려면 상당한 노력이 필요할 수 있습니다. 업계 모범 사례와 표준을 따르고 구현을 최신 상태로 유지해야 합니다.

Container Apps를 위한 기본 제공 인증 기능을 통해 페더레이션 ID 공급자를 통해 기본 인증을 제공하여 시간과 노력을 절감할 수 있습니다. 이러한 기능을 사용하면 애플리케이션 개발에 더 많은 시간을 집중하고 보안 시스템 빌드에 소요되는 시간을 줄일 수 있습니다.

이점은 다음과 같습니다.

Azure Container Apps는 다양한 기본 제공 인증 공급자에 대한 액세스를 제공합니다.
기본 제공 인증 기능에는 특정 언어, SDK, 보안 전문 지식 또는 코드 작성이 필요하지 않습니다.
Microsoft Entra ID, Facebook, Google 및 X를 비롯한 여러 공급자와 통합할 수 있습니다.

ID 공급자

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

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

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

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

이 기능은 HTTPS에만 사용해야 합니다. 컨테이너 앱의 수신 구성에서 allowInsecure가 사용하지 않도록 설정되었는지 확인합니다.

사이트 콘텐츠 및 API에 대한 액세스를 제한하거나 제한하지 않고 인증을 위해 컨테이너 앱을 구성할 수 있습니다. 앱 액세스를 인증된 사용자로만 제한하려면 액세스 제한 설정을 인증 요구로 설정합니다. 액세스를 인증하되 제한하지 않으려면 액세스 제한 설정을 인증되지 않은 액세스 허용으로 설정합니다.

기본적으로 각 컨테이너 앱은 인증을 위해 고유한 쿠키 또는 토큰을 발급합니다. 사용자 고유의 서명 및 암호화 키를 제공할 수도 있습니다.

기능 아키텍처

인증 및 권한 부여 미들웨어 구성 요소는 애플리케이션의 각 복제본에서 사이드카 컨테이너로 실행되는 플랫폼의 기능입니다. 사용하도록 설정되면 애플리케이션은 보안 계층을 통과한 후 들어오는 각 HTTP 요청을 처리합니다.

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

지정된 ID 공급자를 사용하여 사용자와 클라이언트를 인증합니다.
인증된 세션 관리
HTTP 요청 헤더에 ID 정보 삽입

인증 및 권한 부여 모듈은 애플리케이션 코드와 분리된 별도의 컨테이너에서 실행됩니다. 처리 중에는 보안 컨테이너가 실행되지 않으므로 특정 언어 프레임워크와 직접 통합할 수 없습니다. 그러나 이 문서에 설명된 대로 앱에 필요한 관련 정보가 요청 헤더에 제공됩니다.

인증 흐름

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

공급자 SDK 사용 안 함(서버 지향 흐름 또는 서버 흐름): 애플리케이션이 Container Apps에 페더레이션된 로그인을 위임합니다. 위임은 일반적으로 공급자의 로그인 페이지를 사용자에게 제공하는 브라우저 앱을 사용하는 경우입니다.
공급자 SDK 사용(클라이언트 지향 흐름 또는 클라이언트 흐름): 애플리케이션은 사용자를 수동으로 공급자에 로그인시킨 다음, 유효성 검사를 위해 인증 토큰을 Container Apps에 제출합니다. 이 접근 방식은 공급자의 로그인 페이지를 사용자에게 표시하지 않는 브라우저가 없는 앱에서 일반적입니다. 예를 들어 공급자의 SDK를 사용하여 사용자를 로그인시키는 네이티브 모바일 앱이 있습니다.

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

표에는 인증 흐름 단계가 나와 있습니다.

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

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

권한 부여 동작

Azure Portal에서 들어오는 요청이 인증되지 않은 경우 컨테이너 앱의 인증 설정을 편집하여 다양한 동작으로 구성할 수 있습니다. 다음 제목은 옵션을 설명합니다.

인증되지 않은 액세스 허용: 이 옵션은 애플리케이션 코드에 대한 인증되지 않은 트래픽의 권한 부여를 지연시킵니다. 인증된 요청의 경우 Container Apps는 HTTP 헤더의 인증 정보도 전달합니다. 앱은 헤더의 정보를 사용하여 요청에 대한 권한 부여 결정을 내릴 수 있습니다.

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

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

주의

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

참고 항목

기본적으로 Microsoft Entra 테넌트에 있는 모든 사용자는 Microsoft Entra ID에서 애플리케이션에 대한 토큰을 요청할 수 있습니다. 앱에 대한 액세스를 정의된 사용자 세트로 제한하려는 경우 Microsoft Entra ID에서 응용 프로그램을 구성할 수 있습니다.

Container Apps 인증은 로그인 및 로그아웃을 위한 기본 제공 엔드포인트를 제공합니다. 기능이 사용하도록 설정되면 컨테이너 앱의 /.auth 경로 접두사 아래에서 이러한 엔드포인트를 사용할 수 있습니다.

포털 구성은 사용자에게 여러 로그인 공급자(예: Facebook 및 X)를 제공하는 턴키 방법을 제공하지 않습니다. 그러나 앱에 기능을 추가하기는 어렵지 않습니다. 단계는 다음과 같이 간략히 설명됩니다.

먼저 Azure Portal의 인증/권한 부여 페이지에서 사용하도록 설정하려는 각 ID 공급자를 구성합니다.

요청이 인증되지 않은 경우 수행할 작업에서 익명 요청 허용(작업 없음)을 선택합니다.

로그인 페이지, 탐색 모음 또는 앱의 다른 위치에서 사용하도록 설정한 각 공급자에 로그인 링크를 추가합니다(/.auth/login/<provider>). 예시:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

사용자가 링크 중 하나를 선택하면 해당 공급자의 UI가 사용자에게 표시됩니다.

사용자 사후 로그인을 사용자 지정 URL로 리디렉션하려면 post_login_redirect_uri 쿼리 문자열 매개 변수를 사용합니다(ID 공급자 구성의 리디렉션 URI와 혼동하지 않음). 예를 들어 로그인한 후에 사용자를 /Home/Index로 이동하려면 다음 HTML 코드를 사용합니다.

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

클라이언트 지시 로그인에서는 사용자가 애플리케이션에서 공급자별 SDK를 사용하여 ID 공급자에 로그인합니다. 그런 다음, 애플리케이션 코드는 HTTP POST 요청을 사용하여 유효성 검사를 위해 Container Apps에 결과 인증 토큰을 제출합니다(인증 흐름 참조).

공급자 토큰의 유효성을 검사하려면 먼저 원하는 공급자를 사용하여 컨테이너 앱을 구성해야 합니다. 런타임 시 공급자에서 인증 토큰을 검색한 후 유효성 검사를 위해 토큰을 /.auth/login/<provider>에 게시합니다. 예시:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

토큰 형식은 공급자에 따라 약간 다릅니다. 자세한 내용은 다음 표를 참조하세요.

공급자 값	요청 본문에 필요	설명
`aad`	`{"access_token":"<ACCESS_TOKEN>"}`	`id_token`, `refresh_token`, `expires_in` 속성은 선택 사항입니다.
`microsoftaccount`	`{"access_token":"<ACCESS_TOKEN>"}` 또는 `{"authentication_token": "<TOKEN>"`	`authentication_token`이 `access_token`보다 우선합니다. `expires_in` 속성은 선택 사항입니다. Live 서비스에서 토큰을 요청하는 경우 항상 `wl.basic` 범위를 요청합니다.
`google`	`{"id_token":"<ID_TOKEN>"}`	`authorization_code` 속성은 선택 사항입니다. `authorization_code` 값을 제공하면 액세스 토큰과 새로 고침 토큰이 토큰 저장소에 추가됩니다. 지정하면 `authorization_code`에 선택적으로 `redirect_uri` 속성이 포함될 수도 있습니다.
`facebook`	`{"access_token":"<USER_ACCESS_TOKEN>"}`	Facebook에서 유효한 사용자 액세스 토큰을 사용합니다.
`twitter`	`{"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}`

공급자 토큰의 유효성 검사가 성공적으로 수행되면 API는 세션 토큰인 응답 본문에 authenticationToken을 반환합니다.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

이 세션 토큰이 있으면 X-ZUMO-AUTH 헤더를 HTTP 요청에 추가하여 보호된 앱 리소스에 액세스할 수 있습니다. 예시:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

세션에서 로그아웃

사용자는 앱의 /.auth/logout 엔드포인트에 GET 요청을 보내 로그아웃할 수 있습니다. GET 요청은 다음 작업을 수행합니다.

현재 세션에서 인증 쿠키를 지웁니다.
토큰 저장소에서 현재 사용자의 토큰을 삭제합니다.
Microsoft Entra ID 및 Google에 대한 ID 공급자에서 서버 쪽 로그아웃을 수행합니다.

웹 페이지의 단순 로그아웃 링크는 다음과 같습니다.

<a href="/.auth/logout">Sign out</a>

기본적으로 성공적인 로그아웃은 클라이언트를 /.auth/logout/done URL로 리디렉션합니다. post_logout_redirect_uri 쿼리 매개 변수를 추가하여 로그아웃 후 리디렉션 페이지를 변경할 수 있습니다. 예시:

GET /.auth/logout?post_logout_redirect_uri=/index.html

post_logout_redirect_uri 값을 인코딩해야 합니다.

URL은 정규화된 URL을 사용하는 경우 동일한 도메인에서 호스트되어야 합니다.

애플리케이션 코드에서 사용자 클레임에 액세스

Container Apps는 모든 언어 프레임워크에서 들어오는 토큰의 클레임을 애플리케이션 코드에서 사용할 수 있도록 합니다. 클레임은 인증된 최종 사용자 또는 클라이언트 애플리케이션에서 제공하는 요청 헤더에 삽입됩니다. 외부 요청은 이러한 헤더를 설정하도록 허용되지 않았으므로 Container Apps에서 설정한 경우에만 표시됩니다. 다음은 이러한 헤더의 예입니다.

X-MS-CLIENT-PRINCIPAL-NAME
X-MS-CLIENT-PRINCIPAL-ID

모든 언어로 작성된 코드 또는 프레임워크는 이러한 헤더에서 필요한 정보를 가져올 수 있습니다.

참고 항목

다른 언어 프레임워크는 이러한 헤더를 소문자 또는 제목 대/소문자와 같은 다양한 형식으로 앱 코드에 표시할 수 있습니다.

다음 단계

컨테이너 앱 보안에 대한 자세한 내용은 다음 문서를 참조하세요.

다음을 통해 공유

Azure Container Apps의 인증 및 권한 부여

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

ID 공급자

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

기능 아키텍처

인증 흐름

권한 부여 동작

세션에서 로그아웃

애플리케이션 코드에서 사용자 클레임에 액세스

다음 단계

피드백

추가 리소스

다음을 통해 공유

Azure Container Apps의 인증 및 권한 부여

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

ID 공급자

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

기능 아키텍처

인증 흐름

권한 부여 동작

로그인 및 로그아웃 사용자 지정

다중 로그인 공급자 사용

클라이언트 지시 로그인

세션에서 로그아웃

애플리케이션 코드에서 사용자 클레임에 액세스

다음 단계

피드백

추가 리소스