Authenticate AI Connections with Client Credentials

Overview

This guide is for teams whose AI app sits behind an OAuth2-protected gateway, an Azure API gateway, a Databricks serving endpoint, an Auth0-protected API, and similar. These endpoints don't accept a static API key; they expect a short-lived Bearer token that must be fetched from an identity provider first.

The client credentials grant is the machine-to-machine OAuth2 flow for exactly this case. There is no human in the loop, an application identity (a client ID and client secret) exchanges its credentials for an access token. When you configure it on an AI Connection, Confident AI fetches a fresh token from your identity provider and attaches it as Authorization: Bearer <token> on every request it sends to your endpoint.

Two authentication types implement the client credentials grant:

• Azure AD , Microsoft Entra ID / Azure AD. Use this for endpoints protected by Entra, including Azure Databricks serving endpoints.
• Auth0 , Auth0's OAuth2 client credentials flow.

sequenceDiagram
    participant CA as Confident AI
    participant IDP as Identity Provider<br/>(Azure AD / Auth0)
    participant EP as Your AI App Endpoint

    CA->>IDP: POST token endpoint<br/>grant_type=client_credentials<br/>client_id + client_secret + scope
    IDP-->>CA: access_token (short-lived)
    CA->>EP: POST /your-endpoint<br/>Authorization: Bearer access_token
    EP-->>CA: Actual output

Build It

1. Gather your credentials

   Before touching the platform, collect these from your identity provider. The exact names differ between Azure AD and Auth0, but the concepts are the same:

   You need	Azure AD	Auth0
   Application identity	Client ID of your app registration	Client ID of your Auth0 application
   Application secret	Client Secret of your app registration	Client Secret
   Where to get a token	Tenant ID (token URL is built from it)	Auth0 Domain
   What you want access to	Scope (resource identifier + /.default)	Audience (API identifier)

2. Open the Authentication tab

   In your AI Connection, open the Authentication tab and pick your authentication type from the dropdown: Azure AD or Auth0.

   

3. Configure the client credentials fields

   Azure ADAuth0

   Set the Grant Type toggle to Client Credentials (the default), then fill in:

   Field	Value
   Tenant ID	Your Microsoft Entra tenant ID (a GUID)
   Client ID	The app registration's Application (client) ID
   Client Secret	A client secret generated for that app registration
   Scope	The resource you want a token for, suffixed with /.default (e.g. api://<app-id>/.default)

   Leave Username and Password empty those only apply to the Password (ROPC) grant.

4. (Optional) Store secrets in a vault

   Instead of pasting a literal Client Secret into the platform, you can enable the Secrets Manager and provide the name of the secret in your vault (e.g. Azure Key Vault). Confident AI retrieves it at runtime. See Authorization for setup.

5. Ping to verify

   Click Ping to test the connection. Confident AI will fetch a token and call your endpoint:

   • A 200 means the token exchange succeeded and your endpoint accepted the Bearer token. ✅
   • A token-exchange error (400 from the identity provider) means a credential or scope is wrong, see the troubleshooting below.
   • A 401/403 from your endpoint means the token was issued but the identity lacks permission, a RBAC / authorization concern, not an auth-flow problem.

Azure AD and Azure Databricks

The single most common failure is a malformed scope. Client credential flows on the Azure AD v2.0 endpoint require the scope to be the resource identifier suffixed with /.default.

Connecting to a Databricks serving endpoint

Azure Databricks is a fixed Entra resource, so the scope is the same for every workspace:

Point the endpoint URL at your serving endpoint's invocations path, for example:

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

After the token: RBAC

A successful token exchange only proves the service principal authenticated, it does not grant access to the endpoint. If Ping returns a token successfully but your endpoint responds with 403, the service principal needs to be added to the Databricks workspace and granted CAN_QUERY on the serving endpoint. That is an authorization (RBAC) step on the Databricks side, separate from this auth configuration.

Next Steps

Last updated on July 28, 2026