Azure OpenAI authentication patterns without API keys

Problem

API keys are static credentials that must be distributed, rotated, and audited; they are unsuitable for high-assurance environments and agent frameworks at scale. Azure OpenAI supports Microsoft Entra ID authentication, enabling keyless access via managed identities and workload identities. The friction points are: enabling identity where the app is hosted, scoping roles correctly, and handling client capability differences (service vs AKS vs user-interactive).

Options and trade-offs

• System-assigned managed identity (App Service/Functions/Container Apps): Azure hosts present a managed identity; applications obtain Entra access tokens (DefaultAzureCredential) and call Azure OpenAI via the resource's custom subdomain endpoint. Minimal credential handling; role assignment required ("Cognitive Services OpenAI User").
• User-assigned managed identity (App Service/ACA/VMs): Provides explicit identity reuse across multiple hosts; requires client_id configuration and role assignment at resource, RG, or subscription scope. Slightly more setup, clearer scoping.
• AKS Workload Identity: Pods use a Kubernetes service account projected token; a federated identity credential links the service account to a managed identity. This enables short-lived, passwordless authentication to Azure OpenAI from AKS without storing secrets in pods. Requires enabling OIDC issuer, Workload Identity, service account annotations, and pod labeling.
• User-delegated (interactive apps): Use user-based authentication in frontends/worker apps; appropriate when the user context is required (for example, per-user metering or consent). More complexity around token flows, less suitable for daemon agents.

Minimal working example

Prereqs

• .NET 8 or Python 3.9+, Azure.Identity 1.10+ and Azure.AI.OpenAI/Microsoft.Extensions.AI for .NET, or openai 1.x with azure-identity for Python.
• Azure OpenAI resource with a custom subdomain endpoint (required for Entra tokens).
• Role: Cognitive Services OpenAI User assigned to the identity at the resource scope.

A) .NET (App Service with system-assigned MI) Packages: Azure.Identity, Azure.AI.OpenAI, Microsoft.Extensions.AI

using Azure.Identity;
using Azure.AI.OpenAI;

var credential = new DefaultAzureCredential();
var client = new OpenAIClient(new Uri("https://YOUR-RESOURCE.openai.azure.com/"), credential);

var resp = await client.GetChatCompletionsAsync("gpt-4o", new ChatCompletionsOptions
{
    Messages = { new ChatMessage(ChatRole.User, "Hello from Entra auth!") }
});
Console.WriteLine(resp.Value.Choices[0].Message.Content);

Test: Deploy to App Service with identity enabled; assign Cognitive Services OpenAI User on the OpenAI resource; call endpoint and inspect server logs for successful token acquisition. B) AKS Workload Identity (secure access sample) Steps: Enable OIDC issuer and Workload Identity; create user-assigned MI; create federated credential; annotate service account; label pods. Pod manifest snippet:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-service
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: ai-service
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: workload-identity-sa
      containers:
      - name: ai-service
        image: ghcr.io/azure-samples/aks-store-demo/ai-service:latest
        env:
        - name: USE_AZURE_OPENAI
          value: "True"
        - name: USE_AZURE_AD
          value: "True"
        - name: AZURE_OPENAI_DEPLOYMENT_NAME
          value: "DEPLOYMENT"
        - name: AZURE_OPENAI_ENDPOINT
          value: "https://YOUR-RESOURCE.openai.azure.com/"

Test: kubectl apply; confirm tokens acquired via Workload ID; verify successful calls to Azure OpenAI.

Checklist

• Use the OpenAI resource's custom subdomain endpoint for Entra tokens.
• Assign the Cognitive Services OpenAI User role to the managed identity at the correct scope.
• On AKS, enable Workload Identity and OIDC issuer; configure service account annotations and azure.workload.identity/use label.
• Prefer DefaultAzureCredential for host portability; provide client_id for user-assigned MI.
• Map workloads to least-privilege scopes (resource vs RG vs subscription).

Where this doesn't apply

Purely external, non-Azure hosting lacking managed identity support; use service principals with key vault-backed secrets only as a transitional measure (with rotation and audit).

Sources

• Authenticate an Azure hosted .NET app to Azure OpenAI using Entra ID (GA) — https://learn.microsoft.com/en-us/dotnet/ai/how-to/app-service-aoai-auth (accessed 2026-10-13).
• Foundry (classic) Entra auth for Azure OpenAI (GA) — https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/managed-identity (accessed 2026-10-13).
• Secure access to Azure OpenAI from AKS (GA) — https://learn.microsoft.com/en-us/azure/aks/open-ai-secure-access-quickstart (accessed 2026-10-13).

---