클라이언트 자격 증명으로 AI 연결 인증

클라이언트 자격 증명으로 AI 연결 인증 (Authenticate AI Connections with Client Credentials)

OAuth2 보호 AI 앱 엔드포인트에, 매 요청 전에 Confident AI가 클라이언트 자격 증명 그랜트로 토큰을 가져오게 해 연결하는 방법을 설명하는 문서예요. 이 문서에서는 자격 증명 수집, Azure AD와 Auth0 구성, 핑 검증, 그리고 일반적 실패 원인을 다뤄요.

출처: 문서

본문

개요 (Overview)

이 가이드는 AI 앱이 OAuth2 보호 게이트웨이, Azure API 게이트웨이, Databricks serving 엔드포인트, Auth0 보호 API 등 뒤에 있는 팀을 위한 문서예요. 이런 엔드포인트는 정적 API 키를 받지 않고, 먼저 ID 제공자에서 가져와야 하는 단기 Bearer 토큰을 기대해요.

클라이언트 자격 증명(client credentials) 그랜트는 정확히 이 경우를 위한 머신 간 OAuth2 흐름이에요. 사람이 개입하지 않고, 애플리케이션 신원(client ID와 client secret)이 자격 증명을 access token과 교환해요. 이를 AI Connection에 구성하면, Confident AI가 ID 제공자에서 새 토큰을 가져와 엔드포인트로 보내는 모든 요청에 Authorization: Bearer ***로 붙여요.

클라이언트 자격 증명 그랜트를 구현하는 두 가지 인증 유형이 있어요:

Azure AD — Microsoft Entra ID / Azure AD. Azure Databricks serving 엔드포인트를 포함해 Entra로 보호된 엔드포인트에 사용해요.
Auth0 — Auth0의 OAuth2 클라이언트 자격 증명 흐름.

클라이언트 자격 증명은 사용자가 아니라 애플리케이션을 인증하므로, 사용자 이름이나 비밀번호가 없어요. 제공자가 사용자 계정에 대해서만 토큰을 발급한다면 Password(ROPC) 그랜트를 대신 사용할 수 있는데, 이는 대부분 폐기되었고 MFA / Conditional Access에서 깨져요. 서비스 엔드포인트에는 클라이언트 자격 증명을 선호해요.

구축하기 (Build It)

자격 증명 모으기

플랫폼을 만지기 전에 ID 제공자에서 다음을 수집해요. 정확한 이름은 Azure AD와 Auth0에서 다르지만 개념은 같아요:

필요한 것	Azure AD	Auth0
애플리케이션 신원	앱 등록의 Client ID	Auth0 애플리케이션의 Client ID
애플리케이션 시크릿	앱 등록의 Client Secret	Client Secret
토큰을 얻을 곳	Tenant ID (토큰 URL이 여기서 만들어짐)	Auth0 Domain
접근하려는 것	Scope (리소스 식별자 + `/.default`)	Audience (API 식별자)

Azure AD에서는 Tenant ID만 제공하면 돼요. Confident AI가 토큰 엔드포인트 https://login.microsoftonline.com/<tenantId>/oauth2/v2.0/token을 만들어 줘요. 어떤 필드에도 토큰 URL을 붙여 넣지 마세요. 가장 흔한 오류 원인인 scope 형식은 Azure AD 섹션을 참고해요.

Authentication 탭 열기

AI Connection에서 Authentication 탭을 열고 드롭다운에서 인증 유형을 골라요: Azure AD 또는 Auth0.

인증 유형 선택

클라이언트 자격 증명 필드 구성

Azure AD

Grant Type 토글을 Client Credentials(기본값)로 설정하고 다음을 채워요:

필드	값
Tenant ID	Microsoft Entra tenant ID (GUID)
Client ID	앱 등록의 Application (client) ID
Client Secret	그 앱 등록에 생성된 클라이언트 시크릿
Scope	토큰을 받을 리소스에 `/.default`를 붙인 값 (예: `api://<app-id>/.default`)

Username과 Password는 비워 두세요. Password(ROPC) 그랜트에만 적용돼요.

Auth0

Auth0의 클라이언트 자격 증명 흐름은 다음을 요구해요:

필드	값
Auth0 Domain	Auth0 tenant 도메인 (예: `your-tenant.auth0.com`)
Audience	이 토큰이 접근하도록 인가된 API 식별자
Client ID	Auth0 애플리케이션의 client ID
Client Secret	Auth0 애플리케이션의 client secret

(선택) 볼트에 시크릿 저장

플랫폼에 리터럴 Client Secret을 붙여 넣는 대신 Secrets Manager를 활성화하고 볼트(예: Azure Key Vault)의 시크릿 이름을 제공할 수 있어요. Confident AI가 런타임에 검색해요. 설정은 Authorization을 참고해요.

핑으로 검증

Ping을 클릭해 연결을 테스트해요. Confident AI가 토큰을 가져와 엔드포인트를 호출해요:

200은 토큰 교환이 성공했고 엔드포인트가 Bearer 토큰을 받았다는 뜻. ✅
토큰 교환 오류(ID 제공자의 400)는 자격 증명이나 scope가 잘못된 것. 아래 문제 해결을 참고해요.
엔드포인트의 401/403은 토큰은 발급됐지만 신원에 권한이 없는 것. 인증 흐름 문제가 아니라 RBAC / 인가 문제예요.

Azure AD와 Azure Databricks

가장 흔한 실패는 잘못된 scope예요. Azure AD v2.0 엔드포인트의 클라이언트 자격 증명 흐름은 scope가 /.default가 붙은 리소스 식별자여야 해요.

scope는 /.default로 끝나야 해요

Ping에서 다음 오류가 보이면:
AADSTS1002012: The provided value for scope ... is not valid.
Client credential flows must have a scope value with /.default
suffixed to the resource identifier (application ID URI).
거의 항상 다음 중 하나를 의미해요:

Scope에 /.default 접미사가 없음.

Scope 필드에 토큰 URL이 붙여 넣어짐 (예: https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token). 그 값은 scope가 아니고, 안의 tenant GUID는 Tenant ID 필드에 들어가야 하며, Confident AI가 그것으로 토큰 URL을 만들어요.

Databricks serving 엔드포인트에 연결

Azure Databricks는 고정된 Entra 리소스라, scope는 모든 워크스페이스에서 같아요:

필드	값
Tenant ID	Entra tenant GUID
Client ID	서비스 주체의 Application (client) ID
Client Secret	그 서비스 주체용 시크릿
Scope	`7ff2314a6-3904-4as8-12at-gn036f619c0d/.default`

7ff2314a6-3904-4as8-12at-gn036f619c0d는 Azure Databricks 리소스의 전역적이고 잘 알려진 프로그래매틱 ID예요. 모든 워크스페이스에서 동일하므로, 워크스페이스 URL이나 자체 앱 ID로 바꾸지 마세요.

엔드포인트 URL을 serving 엔드포인트의 invocations 경로로 지정해요. 예:

https://adb-<workspace-id>.<n>.azuredatabricks.net/serving-endpoints/<endpoint-name>/invocations

토큰 이후: RBAC

성공적인 토큰 교환은 서비스 주체가 인증되었음을 증명할 뿐, 엔드포인트 접근을 허용하지는 않아요. Ping이 토큰을 성공적으로 반환했는데 엔드포인트가 403으로 응답하면, 서비스 주체를 Databricks 워크스페이스에 추가하고 serving 엔드포인트에 CAN_QUERY를 부여해야 해요. 이는 Databricks 쪽의 인가(RBAC) 단계로, 이 인증 구성과는 별개예요.

클라이언트 자격 증명으로 AI 연결 인증