Fix Azure OpenAI authentication failure behind a TLS-inspecting proxy#6553
Open
subhashpolisetti wants to merge 1 commit into
Open
Fix Azure OpenAI authentication failure behind a TLS-inspecting proxy#6553subhashpolisetti wants to merge 1 commit into
subhashpolisetti wants to merge 1 commit into
Conversation
subhashpolisetti
force-pushed
the
azure-openai-auth-example-com
branch
from
d396045 to
b736db1
Compare
Azure OpenAI authentication acquired its bearer token through AuthenticationUtil.getBearerTokenSupplier, which issues a live HTTPS request to https://www.example.com on every call purely to read the Authorization header back off the request. That extra hop is unnecessary and fails in environments where the connection is not permitted, such as behind a TLS-inspecting proxy requiring custom certificates. Acquire the token from the credential directly, caching it in a small synchronous supplier that refreshes shortly before expiry. This drops the example.com request while preserving the token caching the removed pipeline provided, and keeps token acquisition off the reactive path. Closes spring-projects#6549 Signed-off-by: subhash polisetti <subhashr161347@gmail.com>
subhashpolisetti
force-pushed
the
azure-openai-auth-example-com
branch
from
b736db1 to
d250028
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Azure OpenAI token authentication (Azure CLI or managed identity, rather than an
API key) currently builds its bearer-token supplier with
AuthenticationUtil.getBearerTokenSupplier(...). That supplier issues a liveHTTPS
GET https://www.example.comon every invocation, purely to run thecredential through a
BearerTokenAuthenticationPolicyand read the resultingAuthorizationheader back off the request. Theopenai-javaclient invokesthe supplier while preparing each request, so this hop happens on every call.
The example.com request is unnecessary and fails in environments where such a
connection is not permitted for example behind a TLS-inspecting proxy that
requires custom certificates, where it surfaces as
SSLHandshakeException: ... PKIX path building failed. Importing certificatesinto every application's JVM is an impractical workaround.
This reads the token directly from the credential instead. Since the
azure-identitycredentials do not cache tokens themselves — that is the SDKpipeline's role — it is wrapped in
SimpleTokenCacheto preserve the tokencaching and refresh the previous pipeline provided. No dependency is added (both
types come with the Azure SDK), the acquired token is unchanged, and it
continues to work with any
DefaultAzureCredentialchain (managed identity,workload identity, Azure CLI, etc.).
Testing
Added unit tests in
AzureInternalOpenAiHelperTests:https://cognitiveservices.azure.com/.defaultscope is requested,./mvnw -pl models/spring-ai-openai testpasses; formatting is clean.Closes #6549