Connect to Azure OpenAI without an API key

Replace the application key with a named identity

An application can call an Azure OpenAI resource using Microsoft Entra authentication instead of a stored API key. Grant the calling identity an appropriate inference role on the resource, configure the client to obtain a token and verify a harmless request. For an application hosted on a supported Azure service, a managed identity avoids maintaining an application password or certificate for that authentication step. ^{[1] [2]}

Begin with one known caller and one resource. Record the Azure OpenAI resource ID, endpoint, deployment name and host that will run the application. A migration that starts by disabling keys across a shared resource can interrupt callers that were never included in the test. Identify those callers before changing the resource's authentication policy.

This guide covers direct inference against an Azure OpenAI resource. Microsoft Foundry has both newer and classic experiences, and some referenced resource-level instructions are explicitly marked for the classic portal. The resource, endpoint family and role definition are the stable things to verify. Do not assume a project-level Foundry role or a portal label is interchangeable with the Azure OpenAI resource role described here.

The intended result is more specific than keyless login. The named runtime identity should be able to make the approved inference call, should not need deployment-administration rights and should remain usable after the old key-based caller is retired. Each part deserves its own test. A developer's successful request from a laptop establishes only the developer's path.

Check the Azure resource and endpoint family

Use the endpoint shown for the intended Azure OpenAI resource and confirm the deployed model's deployment name. The client configuration must match the API family being used. Microsoft's endpoint guidance distinguishes Azure endpoint configuration from direct OpenAI configuration, and the Azure request identifies the deployment rather than assuming that an arbitrary model name selects the correct resource. ^[5]

For the documented Azure OpenAI v1 pattern, the client uses the resource's /openai/v1/ base path and a token-provider callback. Check the current authentication example for the required token scope. Different documentation generations and endpoint families can show different audience strings, so copy a coherent supported example rather than combining a token scope from one tutorial with a URL from another. ^{[2] [3]}

A custom subdomain is part of the documented Microsoft Entra authentication prerequisites for Azure OpenAI. If an application has accumulated several endpoint variables, remove ambiguity before changing authentication. An expired key error from the wrong resource and a token authorization error from the right resource can look similar in a hurried support note.

Keep configuration values separate from credentials. The endpoint and deployment name identify where to call; the token provider supplies authentication at runtime. Store those identifiers through the application's normal configuration mechanism without placing tokens in a configuration file. The migration should reduce credential handling, not rename an access token and store it where the API key used to live.

Grant inference access without deployment administration

For the resource-level workflow, Cognitive Services OpenAI User permits Microsoft Entra inference calls and viewing the relevant resource information. It does not grant the same deployment-management capabilities as Cognitive Services OpenAI Contributor. Microsoft's role reference also shows that broader Cognitive Services administration and Entra inference permissions are not identical. Select the role for the runtime task rather than its apparent seniority. ^[1]

Assign the role to the application's identity at the intended Azure OpenAI resource scope. If the same identity already inherits broader roles from a resource group or subscription, record that fact. A narrow new assignment does not subtract existing privileges. The acceptance test should not claim least privilege merely because one correctly scoped role appears in the list.

Keep the deployment administrator separate from the runtime caller. The administrator may need to create models, adjust configuration or manage capacity, while the application normally needs to invoke an already approved deployment. Giving the runtime identity broad administration rights to make setup easier increases what a compromised application could change.

At resource scope, an inference role can cover the deployments available through that resource. Do not describe it as a single-deployment restriction unless the actual supported authorization arrangement enforces that boundary. If different applications require different access domains, review the resource organization and current role capabilities rather than inferring isolation from a deployment name.

Use the developer identity only for local testing

During development, the Azure Identity library can use a signed-in developer credential to obtain a token. Sign in to the correct tenant and verify that the account has the intended resource role. A laptop with access to several subscriptions can otherwise make a successful call using an identity or resource that differs from the planned application deployment. ^[2]

Use harmless input for the first inference call, such as a request to return a short greeting. Do not submit customer records or production prompts merely to validate authentication. Record whether the request succeeded, which deployment handled it and which identity path the client selected. The response content is usually less useful than those configuration facts for this test.

Default credential chains are convenient because they can support local and hosted environments, but convenience creates a testing risk. A local command may succeed through a developer login even when the application's intended managed identity has no access. Microsoft's hosted-Python guidance explains environment-aware credential selection and the option to use a specific managed-identity credential. ^[4]

Treat the local result as a development check. It can validate client configuration and the developer's role, but it cannot establish that the deployed host can obtain the correct token or reach a private endpoint. Keep the hosted acceptance test outstanding until it runs from the actual application environment.

Select the identity used by the hosted application

Enable the managed identity on the Azure resource that hosts the application and record its principal identifier. A system-assigned identity follows that host's lifecycle; a user-assigned identity is a separate resource that can be attached to supported hosts. Choose based on the application's lifecycle and whether multiple hosts intentionally share the same access. ^[6]

When multiple user-assigned identities are attached, select the intended one explicitly. Do not let an ambiguous configuration choose an identity simply because it happens to work. The runbook should name the principal that receives the inference role and the configuration that selects it. A friendly resource name is helpful, but the identity identifier distinguishes replacement or similarly named resources.

Use the supported SDK token-provider integration so that the library can obtain and refresh tokens. The documented Python v1 client accepts a callable in the parameter named api_key; in that pattern the callable returns a token for bearer authentication rather than storing a service API key. Explain that naming detail in code review so that a reviewer does not replace the callback with a copied token string. ^[2]

Network access remains a separate requirement. If the Azure OpenAI resource is restricted to private networks or selected paths, verify DNS and connectivity from the application host. A correct identity role does not bypass network restrictions. The network configuration documentation should be reviewed for the actual resource and endpoint arrangement before interpreting an authentication failure. ^[7]

import os
from azure.identity import ManagedIdentityCredential, get_bearer_token_provider
from openai import OpenAI

credential = ManagedIdentityCredential()
token_provider = get_bearer_token_provider(
    credential, "https://ai.azure.com/.default"
)
client = OpenAI(
    base_url=os.environ["AZURE_OPENAI_ENDPOINT"].rstrip("/") + "/openai/v1/",
    api_key=token_provider,
)
response = client.chat.completions.create(
    model=os.environ["AZURE_OPENAI_DEPLOYMENT"],
    messages=[{"role": "user", "content": "Return a short greeting."}],
)
print("Harmless inference returned a response:", bool(response.choices))

Source. Microsoft documentation: Role-based access control for Azure OpenAI (classic) - Microsoft Foundry (classic) portal ^[1]; How to configure Azure OpenAI in Microsoft Foundry Models with Microsoft Entra ID authentication (classic) - Microsoft Foundry (classic) portal ^[2]; Authenticate Azure-hosted Python apps to Azure resources using a system-assigned managed identity - Python on Azure ^[4]; Managed identities for Azure resources - Managed identities for Azure resources ^[6].

Method. Original conceptual synthesis of the cited Microsoft documentation. No deployment measurements or risk scores. Reviewed 2026-09-12.

Accessible table and figure data

Figure 1 accessible table

From	To	Purpose
Azure application	Managed identity credential	Select the intended principal
Credential	Microsoft Entra ID	Obtain the endpoint-appropriate token
SDK client	Azure OpenAI resource	Send bearer-authenticated inference
Resource	Application	Enforce the inference role and return result

Figure 1 accessible table

From	To	Purpose
Azure application	Managed identity credential	Select the intended principal
Credential	Microsoft Entra ID	Obtain the endpoint-appropriate token
SDK client	Azure OpenAI resource	Send bearer-authenticated inference
Resource	Application	Enforce the inference role and return result

Download imageDownload table CSV

Prove a real inference call with harmless input

Run the client from the hosted environment using the intended managed identity. Make one bounded harmless request against the approved deployment and retain a sanitized result. Confirm that no API key is supplied through an overlooked environment variable, secret reference or gateway configuration. The test is incomplete if the application silently falls back to the old authentication route.

Verify the selected role and identity as well as the successful response. If the runtime identity has inherited administration rights, a successful inference call cannot demonstrate that the narrow role alone is sufficient. Use an isolated test identity where necessary, or document the limitation rather than presenting the result as a clean permission-boundary test.

A useful negative check uses a separate test identity without the inference role against the same harmless request, where authorized. The expected denial helps establish that the request is not succeeding through an API key or another unintended path. Do not remove a production identity's role solely to create the negative case. Use a test whose possible success would not expose sensitive data or change the resource.

Also inspect the application's failure behavior. An authentication error should produce a controlled failure and useful sanitized telemetry, not a loop that restores an API key from an old configuration file. The new path must remain understandable when it fails. That is when hidden fallbacks and mixed credentials are most likely to obscure the cause.

Retire key access after the callers are ready

After every intended caller has passed its own token-based test, review whether local key authentication can be disabled for the resource. Microsoft exposes a disableLocalAuth property and documents resource and policy-based management of that setting. Apply the change through the environment's normal configuration process so that a later deployment does not reverse it. ^[8]

Do not treat a true control-plane property as immediate proof that every key-based request is rejected. Microsoft's current guidance explains that gateway configuration can take time to propagate and can take several hours in some conditions. It explicitly recommends a data-plane check using the previously valid key before concluding that local authentication is fully disabled. ^[8]

Perform that negative check with the approved test client and harmless input. Preserve the error status and sanitized service response, without logging the key. Continue to verify that the token-based caller works. The two outcomes together establish that the intended authentication path remains available while the old path is no longer accepted for the checked endpoint.

A rollback plan should account for propagation too. Re-enabling local authentication is not necessarily instantaneous. Avoid promising operators that toggling one setting will immediately restore every caller. The safer migration sequence is to identify callers, verify tokens, change policy, observe both paths and retain an explicit recovery procedure for the actual service.

Source. Microsoft documentation: How to configure Azure OpenAI in Microsoft Foundry Models with Microsoft Entra ID authentication (classic) - Microsoft Foundry (classic) portal ^[2]; Disable local authentication in Foundry Tools - Foundry Tools ^[8].

Method. Original conceptual synthesis of the cited Microsoft documentation. No deployment measurements or risk scores. Reviewed 2026-09-12.

Accessible table and figure data

Figure 2 accessible table

Stage	Token-based call	Previously valid key call
Before migration	Not yet verified	Existing route may work
Before disabling keys	Intended runtime succeeds	Callers inventoried
After policy and propagation	Still succeeds	Actual request is denied
Evidence limit	Checked operation and deployment	Property alone is insufficient

Figure 2 accessible table

Stage	Token-based call	Previously valid key call
Before migration	Not yet verified	Existing route may work
Before disabling keys	Intended runtime succeeds	Callers inventoried
After policy and propagation	Still succeeds	Actual request is denied
Evidence limit	Checked operation and deployment	Property alone is insufficient

Download imageDownload table CSV

Remove old credential copies from the application release

Disabling key authentication at the resource and removing key material from the application are related but separate changes. Inventory the places where the application previously obtained its key, including environment configuration, secret references, deployment variables and local development settings. Remove the obsolete reference through the system that owns it. Do not assume that deleting one variable in a running container also changes the next release's configuration.

Review the application's startup and fallback logic. A code path that tries an API key after token acquisition fails can make a migration appear successful while retaining the old dependency. The intended hosted configuration should select the managed identity clearly and fail in a controlled way if that identity cannot be used. If a temporary fallback is deliberately retained during migration, document its owner and removal condition rather than hiding it inside a generic client helper.

Handle historical credential exposure through the existing secret-management process. If a real key was committed or logged, coordinate the credential response and any repository or build-record cleanup with their owners. Treat that work as a separate change with its own evidence. Removing the current application reference is useful, but it does not establish that every historical copy has disappeared or that another consumer has stopped using the key.

Update deployment checks to look for the required endpoint, deployment name and identity selector, together with the absence of an active key reference in the intended runtime configuration. Those checks should inspect configuration names and state without printing secret values. A release that accidentally restores an old key variable should be visible before the team relies on the resource's authentication policy to reject it.

Finally, keep the ownership record useful for replacement hosts. A new app host may receive a different system-assigned identity, while a deliberately reused user-assigned identity has its own attachment and role requirements. Treat that lifecycle decision as part of deployment review. The migration is easier to maintain when the configuration names the intended principal and the acceptance test runs through the actual released application.

Record which API operation the acceptance test uses. A successful chat-completion request demonstrates that operation on the checked deployment; it does not prove access to every file, fine-tuning, stored-response or administration feature exposed by the service. Keep the runtime role tied to the application's actual operations. If a later feature needs another capability, review that request explicitly instead of broadening the identity during an unrelated authentication repair.

Diagnose failures without restoring broad access

For a 401 or 403 response, first confirm the resource endpoint, token audience, selected principal and role scope. Check whether the role change is recent and allow the documented propagation interval. A token for the wrong resource is not fixed by assigning Contributor, and a network denial is not fixed by changing the client secret that the application no longer needs.

If local development works but the hosted application fails, compare the identities selected in each environment. Check that the host identity is enabled, explicitly selected where necessary and assigned to the intended Azure OpenAI resource. Also compare endpoint configuration and private DNS behavior. The difference between the two environments is often more informative than the fact that they run similar source code.

If the key-based negative test still succeeds after local authentication was disabled, preserve the observation and verify the exact resource and endpoint before assuming the setting was ignored. Confirm the control-plane property, allow the documented propagation behavior and retest within the agreed procedure. Do not claim completion while the old path remains accepted.

Keep the migration record current as hosts and deployments change. It should identify the runtime principal, resource scope, endpoint family, role assignment, token-provider configuration and test results for both authentication paths. The benefit of moving away from a shared API key is clearest when the application has a named identity whose access can be explained, reviewed and removed without searching for copied credentials.