Custom connector authentication: API Key vs OAuth authorization code vs client credentials vs Entra ID
Verdict: API Key for a fixed header key, authorization code when each user signs in, client credentials for one shared service identity, Entra ID as the default. Client credentials are unsupported when creating a connector from an OpenAPI definition.
| Criterion | API Key | Basic | OAuth authorization code | OAuth client credentials | Microsoft Entra ID |
|---|---|---|---|---|---|
| Use when | Backend expects a fixed key in a header or query string | Backend validates username and password | Each maker must sign in with their own identity | All runs use one shared application identity | Azure-secured API, no custom auth code wanted |
| Interactive user sign-in | No | No | Yes, per user | No | No |
| Supported at connector creation from OpenAPI | Yes | Yes | Yes | No | Yes |
Rules
- Choose API Key when the backend expects a fixed subscription key sent in a header or query string parameter.
- Choose OAuth 2.0 client credentials for a shared service identity with no per-user prompt; authorization code flow instead makes each user sign in.
- Microsoft Entra ID is the recommended default: it can be configured in the Azure portal, avoiding auth code in the backend API.
- A non-interactive server app or a flow calling a secured Azure Function authenticates as an Entra app registration (service principal) using client credentials.
Traps
- Creating a custom connector from an OpenAPI definition does not support client credentials in the OAuth security definition, despite it being the natural service-to-service choice.
- Basic authentication sends a username and password pair, not a single subscription key; do not use it where an API Key is expected.
- In some regions the connector OperationId is returned base64 encoded, so decode it defensively before comparing against an expected string.