Skip to content

Fix AzureOpenAI keyless auth by deferring credential validation to SDK#2464

Open
ppon1086 wants to merge 1 commit intoconfident-ai:mainfrom
ppon1086:fix/azure-auth-defer
Open

Fix AzureOpenAI keyless auth by deferring credential validation to SDK#2464
ppon1086 wants to merge 1 commit intoconfident-ai:mainfrom
ppon1086:fix/azure-auth-defer

Conversation

@ppon1086
Copy link

What changed

  • Defer Azure OpenAI authentication validation to the OpenAI SDK
  • Fail fast only when a credential is explicitly provided but empty
  • Preserve existing behavior for key-based authentication
  • Support SecretStr and string credentials consistently

Why this is needed

DeepEval currently raises an error when api_key is missing or empty for AzureOpenAIModel, even when key-based authentication is intentionally disabled and Azure AD / managed identity is intended. This prevents valid keyless Azure OpenAI configurations from working and causes an early failure before the OpenAI SDK can resolve authentication.

This PR removes premature client-side enforcement and defers authentication handling to the official OpenAI/Azure SDK, aligning DeepEval’s behavior with Azure OpenAI’s documented authentication model and avoids false negative configuration errors.

Tests

  • Added unit tests covering:
    • Keyless / managed identity scenarios
    • Explicit empty credential failures
    • SecretStr handling
  • All existing tests pass

Related issue

Fixes #2431

@vercel
Copy link

vercel bot commented Jan 31, 2026

@ppon1086 is attempting to deploy a commit to the Confident AI Team on Vercel.

A member of the Team first needs to authorize it.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 31, 2026

PR author is not in the allowed authors list.

Copy link
Collaborator

@A-Vamshi A-Vamshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ppon1086, just left a few comments that I'm curious about, could you please clarify on these? Thank you!

azure_deployment=self.deployment_name,
azure_ad_token_provider=self.azure_ad_token_provider,
azure_ad_token=azure_ad_token,
azure_ad_token=self.azure_ad_token_value,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we're using self.azure_ad_token_value here and not azure_ad_token_value you created above?

except Exception:
azure_ad_token_value = str(self.azure_ad_token)

if self.azure_ad_token_provider is None:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this block we're following a precedence, we're giving priority to azure_ad_token_provider first, if that doesn't exist we give priority to azure_ad_token over api_key. This allows us to handle the case where a user provides all 3 of these fields (azure_ad_token_provider > azure_ad_token > api_key), since we're already populating api_key_value and azure_ad_token_value which are all being passed to the client below, I'm worried about which one is used by the client in this case? Do you know what happens in this case and if it's safe to do this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deepeval AzureOpenAI requires an api_key even when key based auth is disabled

2 participants