Fix Azure OpenAI authentication failure behind a TLS-inspecting proxy

[subhashpolisetti]

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 live
HTTPS GET https://www.example.com on every invocation, purely to run the
credential through a BearerTokenAuthenticationPolicy and read the resulting
Authorization header back off the request. The openai-java client invokes
the 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 certificates
into every application's JVM is an impractical workaround.

This reads the token directly from the credential instead. Since the
azure-identity credentials do not cache tokens themselves — that is the SDK
pipeline's role — it is wrapped in SimpleTokenCache to preserve the token
caching 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 DefaultAzureCredential chain (managed identity,
workload identity, Azure CLI, etc.).

Testing

Added unit tests in AzureInternalOpenAiHelperTests:

• the token is resolved from the credential (no HTTP client in the path),
• the https://cognitiveservices.azure.com/.default scope is requested,
• the cached token is reused across calls (the credential is queried once).

./mvnw -pl models/spring-ai-openai test passes; formatting is clean.

Closes #6549

[sdeleuze]

Could you please add an integration test that demonstrates the issue (broken without the fix, passing with the fix)?

[subhashpolisetti]

I looked into this and couldn't find a way to write a self-contained test that fails without the fix, because the failure is environmental.

The old code used AuthenticationUtil.getBearerTokenSupplier(credential, scope). Its supplier does a sendSync(GET https://www.example.com) on every call, just to read back the Authorization header. The URL is hardcoded and there's no way to inject an HttpClient, so on a normal network (including CI) it succeeds. I checked, and the existing tests actually pass against both the old and new code. It only breaks behind a TLS-inspecting proxy that fails the example.com handshake (the PKIX error from the issue), which I can't reproduce deterministically in CI.

The unit tests I added cover the new behavior: token resolved via getTokenSync with the cognitiveservices.azure.com/.default scope, cached across calls, no example.com round-trip.

The only way I found to force a failure is overriding the default Azure HttpClient via ServiceLoader, but that's JVM-wide and would affect the other tests in the module. Happy to add it if you're fine with that, or take a different approach if you have one in mind.

[sdeleuze]

Ok thanks for the additional context, I will have a deeper look during the review.