Repository navigation
[Python] Support using keyless auth for Azure OpenAI #216
Description
We try to use keyless auth for all our samples, so if I were to use TypeChat in them, it'd need to support keyless auth, aka this constructor:
openai_client = AsyncAzureOpenAI(
api_version=api_version,
azure_endpoint=endpoint,
azure_ad_token_provider=token_provider,
)
I'd be happy to just pass in my whole client to typechat as I typically already have it configured correctly for other uses in my app. Trying to match environment variables will be a pain since we have existing environment variable names that arent the same as yours.
Activity
pamelafox commentedon Apr 23, 2024
Keyless auth is now a strict requirement for all our samples, so this a blocker for us.
robgruen commentedon Nov 3, 2026
The TypeScript implemenation supports this...we should port that do the Python implementation.
robgruen commentedon Nov 3, 2026
/typechat draft
github-actions commentedon Nov 3, 2026
TypeChat: Draft prepared; owner or maintainer input is still needed before work acceptance.
Owner request | Run and preview
Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.
robgruen commentedon Nov 3, 2026
I think we should modify the public API so that callers can provide a configured client/token provider. We should be careful to maintain backward compatibility.
robgruen commentedon Nov 3, 2026
/typechat draft
github-actions commentedon Nov 3, 2026
TypeChat: Draft prepared; owner or maintainer input is still needed before work acceptance.
Owner request | Run and preview
Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.
robgruen commentedon Nov 3, 2026
/typechat publish 13208841811:36d43ed7696cc2e2abf27c7d86dc2ae443d724c13dd789ed6004dc7d60b1b56a
robgruen commentedon Nov 3, 2026
/typechat reply
github-actions commentedon Nov 3, 2026
You can keep your existing configuration names: TypeChatJsonTranslator accepts a TypeChatLanguageModel, the interface with an asynchronous complete method that returns response text in Success or an error in Failure. An application-side adapter can wrap your configured AsyncAzureOpenAI client and use its keyless authentication, meaning identity tokens instead of a stored API key, while TypeChat retains schema validation and repair. This is a custom adapter path, not direct client injection into the built-in factory.
The built-in Azure factory is narrower: create_azure_openai_language_model takes a fixed credential string and the full chat-completions URL, including deployment and API version, and creates its own network client. It already sets an authorization header intended for managed identity, but it has no token-provider callback, a function that obtains a current identity token, or parameter for an existing OpenAI client. Its fixed headers do not provide automatic token renewal.
Would a public token-provider hook with explicit endpoint configuration meet your sample requirements, or do you need direct reuse of your configured AsyncAzureOpenAI client to preserve its other settings? That distinction would help focus an extension to the existing integration while preserving current API-key calls.
Related contributions: #139, #198, #436, #446.
Automated response requested by the project owner. This does not accept work or authorize implementation.
robgruen commentedon Nov 3, 2026
I think Pamela is requesting a reuse of a configured client so that tokens can be refreshed automatically, etc.
robgruen commentedon Nov 3, 2026
Draft PR #516 is ready for review.
It adds two opt-in Python integration paths:
AsyncOpenAI/AsyncAzureOpenAIor compatible async Chat Completions client, preserving application-owned configuration and lifecycle.There are no additional TypeChat dependencies or required environment-variable changes. Existing factory arguments, API-key behavior, environment configuration, validation, and repair remain intact.
Local validation passed: 41 deterministic tests, Pyright with zero errors/warnings, and mocked interoperability/type checks against genuine OpenAI and Azure OpenAI SDK clients. No live model calls or credentials were used.
The PR remains a draft for human review; no merge is requested.
robgruen commentedon Nov 6, 2026
#516 has been merged.