Skip to main content

Azure Authentication Methods

Comparison of authentication approaches for accessing Azure resources (e.g., Storage, Key Vault) from CI/CD or Kubernetes workloads.

1. OIDC (Workload Identity Federation) — Recommended​

Pros:

  • Most secure — no secrets to store
  • No secret rotation needed
  • Microsoft's recommended approach
  • Works with self-hosted runners
  • Fine-grained access control

Cons:

  • Requires one-time federated credential setup
  • Slightly more complex initial configuration

Best for: Production CI/CD pipelines, long-term maintenance

2. Service Principal with Client Secret​

Pros:

  • Simpler to set up initially
  • Works reliably
  • Well-documented

Cons:

  • Requires storing client secret in GitHub Secrets or similar
  • Secret rotation needed periodically (every 90 days recommended)
  • Less secure than OIDC

Best for: Quick setup, temporary solutions

3. Storage Account Key​

Pros:

  • Simplest setup
  • Direct access

Cons:

  • Least secure (full access to storage account)
  • Manual key rotation
  • Not recommended for production

Best for: Development/testing only

Recommendation​

Use OIDC (Workload Identity Federation) for production. Configure federated credentials once, then use --auth-mode login in Azure CLI or SDK authentication.

Azure CLI Authentication​

When using OIDC with GitHub Actions:

- uses: azure/login@v1
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

No client-secret is needed with federated credentials.

References​