C++용 Azure ID 클라이언트 라이브러리의 자격 증명 체인

Azure ID 클라이언트 라이브러리는 Azure Core 라이브러리의 TokenCredential 추상 기본 클래스에서 파생되는 공용 형식인 자격 증명을 제공합니다. 자격 증명은 Microsoft Entra ID에서 액세스 토큰을 획득하기 위한 고유한 인증 흐름을 나타냅니다. 이러한 자격 증명을 함께 연결하여 순서가 있는 일련의 인증 메커니즘을 시도할 수 있도록 구성할 수 있습니다.

연결된 자격 증명의 작동 방식

런타임 시 자격 증명 체인은 시퀀스의 첫 번째 자격 증명을 사용하여 인증을 시도합니다. 해당 자격 증명이 액세스 토큰을 획득하지 못하면 액세스 토큰을 성공적으로 가져올 때까지 시퀀스의 다음 자격 증명이 시도됩니다. 다음 시퀀스 다이어그램은 이 동작을 보여 줍니다.

자격 증명 체인을 사용하는 이유는 무엇인가요?

연결된 자격 증명은 다음과 같은 이점을 제공할 수 있습니다.

• 환경 인식: 앱이 실행 중인 환경에 따라 가장 적합한 자격 증명을 자동으로 선택합니다. 이 코드가 없으면 다음과 같은 코드를 작성해야 합니다.

  // Set up credential based on environment (Azure or local development)
  std::shared_ptr<Azure::Core::Credentials::TokenCredential> credential;
  if (std::getenv("WEBSITE_HOSTNAME"))
  {
      credential = std::make_shared<Azure::Identity::ManagedIdentityCredential>();
  }
  else
  {
      credential = std::make_shared<Azure::Identity::AzureCliCredential>();
  }
  

• 원활한 전환: 앱은 인증 코드를 변경하지 않고 로컬 개발에서 스테이징 또는 프로덕션 환경으로 이동할 수 있습니다.

• 향상된 복원력: 이전에 액세스 토큰을 획득하지 못한 경우 다음 자격 증명으로 이동하는 대체 메커니즘을 포함합니다.

연결된 자격 증명을 선택하는 방법

C++를 사용하면 자격 증명 체인을 선택할 수 있는 두 가지가 있습니다.

• 미리 구성된 체인사용: DefaultAzureCredential 형식으로 구현된 미리 구성된 체인을 사용합니다. 이 접근 방식에 대해서는 DefaultAzureCredential 개요 섹션을 참조하세요.
• 사용자 지정 자격 증명 체인빌드: 빈 체인으로 시작하고 필요한 것만 포함합니다. 이 접근 방식에 대해서는 ChainedTokenCredential 개요 섹션을 참조하세요.

DefaultAzureCredential 개요

DefaultAzureCredential 은 특정 의도를 가진 미리 구성된 자격 증명 체인입니다. 디자인은 가장 일반적인 인증 흐름 및 개발자 도구와 함께 많은 환경을 지원합니다. 도식 형식의 기본 연결 구조는 다음과 같습니다.

DefaultAzureCredential이 자격 증명을 시도하는 순서는 다음과 같습니다.

가장 간단한 형태인 DefaultAzureCredential의 매개변수 없는 버전은 다음과 같이 사용할 수 있습니다:

#include <azure/identity/default_azure_credential.hpp>
#include <azure/storage/blobs/blob_client.hpp>

int main()
{
    // create a credential
    auto credential = std::make_shared<Azure::Identity::DefaultAzureCredential>();

    // create a Blob service client
    auto blobUrl = "https://<my_account_name>.blob.core.windows.net/mycontainer/myblob";
    Azure::Storage::Blobs::BlobClient blobClient{blobUrl, credential};
}

DefaultAzureCredential을 사용자 지정하는 방법

전체 Developer tool 또는 Deployed service 자격 증명을 제외하려면 환경 변수 AZURE_TOKEN_CREDENTIALS를 prod 또는 dev로 각각 설정합니다. 값 prod 이 사용되는 경우 기본 자격 증명 체인은 다음과 같습니다.

값 dev이 사용되면 체인에는 AzureCliCredential만 포함됩니다.

ChainedTokenCredential 개요

ChainedTokenCredential은 앱의 필요에 맞게 자격 증명을 추가하는 빈 체인입니다. 다음은 그 예입니다.

#include <azure/identity/azure_cli_credential.hpp>
#include <azure/identity/chained_token_credential.hpp>
#include <azure/identity/managed_identity_credential.hpp>
#include <azure/storage/blobs/blob_client.hpp>

int main()
{
    // create a credential
    auto credential = std::make_shared<Azure::Identity::ChainedTokenCredential>(
        Azure::Identity::ChainedTokenCredential::Sources{
            std::make_shared<Azure::Identity::ManagedIdentityCredential>(),
            std::make_shared<Azure::Identity::AzureCliCredential>()});

    // create a Blob service client
    auto blobUrl = "https://<my_account_name>.blob.core.windows.net/mycontainer/myblob";
    Azure::Storage::Blobs::BlobClient blobClient{blobUrl, credential};
}

앞의 코드 샘플은 두 개의 자격 증명으로 구성된 맞춤형 자격 증명 체인을 만듭니다. ManagedIdentityCredential 먼저 시도되고, 필요한 경우 AzureCliCredential이어서 시도됩니다. 그래픽 형태에서의 체인은 다음과 같이 보입니다.

DefaultAzureCredential에 대한 사용 지침

DefaultAzureCredential 의심할 여지 없이 Azure ID 클라이언트 라이브러리를 시작하는 가장 쉬운 방법이지만 이러한 편의상 장단점이 있습니다. Azure에 앱을 배포한 후에는 앱의 인증 요구 사항을 이해해야 합니다. 이러한 이유로 DefaultAzureCredentialTokenCredential같은 특정 ManagedIdentityCredential 구현으로 대체합니다.

그 이유는 다음과 같습니다.

• 디버깅 문제: 인증에 실패하면 잘못된 자격 증명을 디버깅하고 식별하는 것이 어려울 수 있습니다. 한 자격 증명에서 다음 자격 증명으로의 진행률과 각 자격 증명의 성공/실패 상태를 보려면 로깅을 사용하도록 설정해야 합니다. 자세한 내용은 연결된 자격증명 디버깅하기를 참조하세요.
• 성능 오버헤드: 여러 자격 증명을 순차적으로 시도하는 프로세스로 인해 성능 오버헤드가 발생할 수 있습니다. 예를 들어 로컬 개발 머신에서 실행하는 경우 관리 ID를 사용할 수 없습니다. 따라서 ManagedIdentityCredential 로컬 개발 환경에서는 항상 실패합니다.
• 예측할 수 없는 동작: DefaultAzureCredential 특정 환경 변수가 있는지 확인합니다. 누군가 호스트 컴퓨터의 시스템 수준에서 이러한 환경 변수를 추가하거나 수정할 수 있습니다. 이러한 변경 사항은 전역적으로 적용되므로 해당 컴퓨터에서 실행 중인 모든 앱에서 런타임 시 DefaultAzureCredential의 동작이 변경됩니다.

연결된 자격 증명을 디버그하다

예기치 않은 문제를 진단하거나 체인화된 자격 증명이 어떤 역할을 하는지 파악하려면 앱에서 로깅을 활성화하세요. 설명을 위해 매개 변수가 없는 형식 DefaultAzureCredential 이 Blob Storage 계정에 대한 요청을 인증하는 데 사용된다고 가정합니다. 앱은 로컬 개발 환경에서 실행되고 개발자는 Azure CLI를 사용하여 Azure에 인증됩니다. 앱이 실행되면 출력에 다음과 같은 관련 항목이 표시됩니다.

DEBUG : Identity: Creating DefaultAzureCredential which combines multiple parameterless credentials into a single one.
DefaultAzureCredential is only recommended for the early stages of development, and not for usage in production environment.
Once the developer focuses on the Credentials and Authentication aspects of their application, DefaultAzureCredential needs to be replaced with the credential that is the better fit for the application.
INFO  : Identity: EnvironmentCredential gets created with ClientSecretCredential.
DEBUG : Identity: EnvironmentCredential: 'AZURE_TENANT_ID', 'AZURE_CLIENT_ID', and 'AZURE_CLIENT_SECRET' environment variables are set, so ClientSecretCredential with corresponding tenantId, clientId, and clientSecret gets created.
WARN  : Identity: Azure Kubernetes environment is not set up for the WorkloadIdentityCredential credential to work.
DEBUG : Identity: ManagedIdentityCredential: Environment is not set up for the credential to be created with App Service 2019 source.
DEBUG : Identity: ManagedIdentityCredential: Environment is not set up for the credential to be created with App Service 2017 source.
DEBUG : Identity: ManagedIdentityCredential: Environment is not set up for the credential to be created with Cloud Shell source.
DEBUG : Identity: ManagedIdentityCredential: Environment is not set up for the credential to be created with Azure Arc source.
INFO  : Identity: ManagedIdentityCredential will be created with Azure Instance Metadata Service source.
Successful creation does not guarantee further successful token retrieval.
INFO  : Identity: AzureCliCredential created.
Successful creation does not guarantee further successful token retrieval.
INFO  : Identity: DefaultAzureCredential: Created with the following credentials: EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredential, AzureCliCredential.
DEBUG : Identity: DefaultAzureCredential: Failed to get token from EnvironmentCredential: GetToken(): error response: 400 Bad Request

{"error":"invalid_grant","error_description":"AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Trace ID: 11223344-5566-7788-9900-aabbccddeeff Correlation ID: ffeeddcc-bbaa-9988-7766-554433221100 Timestamp: 2025-03-07 21:25:44Z","error_codes":[53003],"timestamp":"2025-03-07 21:25:44Z","trace_id":"11223344-5566-7788-9900-aabbccddeeff","correlation_id":"ffeeddcc-bbaa-9988-7766-554433221100","error_uri":"https://login.microsoftonline.com/error?code=53003","suberror":"message_only","claims":"{\"access_token\":{\"capolids\":{\"essential\":true,\"values\":[\"01234567-89ab-cdef-fedc-ba9876543210\"]}}}"}
WARN  : Identity: WorkloadIdentityCredential authentication unavailable. See earlier WorkloadIdentityCredential log messages for details.
DEBUG : Identity: DefaultAzureCredential: Failed to get token from WorkloadIdentityCredential: WorkloadIdentityCredential authentication unavailable. Azure Kubernetes environment is not set up correctly.
INFO  : Identity: DefaultAzureCredential: Successfully got token from ManagedIdentityCredential. This credential will be reused for subsequent calls.
DEBUG : Identity: DefaultAzureCredential: Saved this credential at index 2 for subsequent calls.

앞의 출력에서 이를 확인할 수 있습니다:

• EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredential이 각각 Microsoft Entra 액세스 토큰을 획득하지 못했습니다(순서대로).
• ManagedIdentityCredential 는 "Successfully got token from ManagedIdentityCredential"로 시작하는 항목으로 표시된 대로 성공합니다.