fix(azure): send JWT api_key values as Bearer token#3283
Conversation
When an Azure AD access token (JWT starting with "eyJ") is passed via the api_key parameter to AzureOpenAI, send it as Authorization: Bearer <token> instead of api-key: <token> to restore the behavior from v2.33.0 and fix 401 errors from Azure APIM/proxy setups.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f8745fa0b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if self.api_key.startswith("eyJ"): | ||
| return {"Authorization": f"Bearer {self.api_key}"} |
There was a problem hiding this comment.
eyJ-prefixed key as JWT
This branch treats every api_key starting with eyJ as an Entra bearer token and moves it from api-key to Authorization, but api_key values are opaque and this prefix check is not a reliable JWT validation. In environments that pass non-JWT secrets (for example APIM subscription keys or other opaque keys) that happen to begin with eyJ, requests will now be sent with the wrong auth header and can fail with 401s. The detection should verify JWT structure/content more robustly (or be opt-in) before switching header types.
Useful? React with 👍 / 👎.
1 participant
When an Azure AD access token (JWT) is passed via
api_key=toAzureOpenAI, the client now sends it asAuthorization: Bearer <token>instead ofapi-key: <token>. The JWT is detected by checking whether the value starts with"eyJ"(the base64-encoded{"that begins every JWT header). This restores the behavior from v2.33.0 where such tokens worked correctly through Azure APIM/proxy setups that validate Bearer tokens. The same fix is applied to bothAzureOpenAIandAsyncAzureOpenAI, in both_auth_headersand_prepare_options.Fixes #3282