Do you deploy to Azure from GitHub Actions with OIDC instead of secrets?

Read Do you use OIDC instead of long-lived secrets in your pipelines? first. This rule covers the GitHub Actions to Azure specifics.

If your workflow still logs in to Azure with a service principal client secret saved as AZURE_CREDENTIALS, replace it with a federated credential. Each workflow run gets a short-lived token that Azure accepts only from the repository and environment you name, and there is nothing left in GitHub to leak or rotate.

How to set it up

1. Create the identity in Azure

Create an app registration (or a user-assigned managed identity) for the deployment, and give it the least privilege it needs, for example Contributor on a single resource group instead of the whole subscription. Do not create a client secret for it.

2. Add a federated credential

On the app registration, add a federated credential for GitHub Actions. The subject says exactly what is trusted:

Scope the subject to a GitHub environment, not just the repository. Then the environment's protection rules (required reviewers, allowed branches) decide who can deploy.

3. Protect the GitHub environment

In the repository settings, create the environment (for example production), limit it to protected branches, and require a pull request approval before a deployment starts.

4. Log in from the workflow

Give the job permission to request a token, name the environment, and pass the identifiers to azure/login. There is no AZURE_CREDENTIALS and no secret key.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

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

      - run: az webapp deploy --resource-group my-rg --name my-app --src-path ./app.zip

✅ Figure: Good example - The workflow signs in with a short-lived token. The three IDs identify the app but are not credentials

- uses: azure/login@v1
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}

❌ Figure: Bad example - AZURE_CREDENTIALS holds a client secret that works from anywhere until it expires or someone rotates it

When you still need something else

• A target that cannot use federation still needs a secret. Keep it in a vault and see Do you use enterprise secrets in your DevOps pipelines?
• Code that runs inside Azure (an App Service or a Function) should use a managed identity at runtime, not a federated credential. See Do you use Managed Identity in Azure?

Learn more

• Configuring OpenID Connect in Azure (GitHub Docs)
• Azure Login action