CI/CD with GitHub Actions and OIDC

Federated credentials instead of client secrets

A pipeline needs an Azure identity to deploy. The old approach stored a service principal's client secret in the CI system, which expires, leaks and is hard to rotate. The recommended approach is workload identity federation with OpenID Connect (OIDC): you create an Entra app registration (or a user-assigned managed identity), add a federated credential that trusts tokens from GitHub for a specific repository and branch or environment, and grant it a narrowly scoped role. At run time GitHub issues a short-lived token, Entra exchanges it for an Azure token, and no secret is stored anywhere. The same pattern works for Azure DevOps, GitLab and Kubernetes workloads.

A GitHub Actions job using OIDC

Only IDs are stored as repository variables; none of them is a secret.

name: deploy-infra
on:
  push:
    branches: [main]

permissions:
  id-token: write   # allow the job to request an OIDC token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az deployment group what-if -g rg-shop-prod-cin -f infra/main.bicep
      - run: az deployment group create  -g rg-shop-prod-cin -f infra/main.bicep

A visitor badge instead of a house key

A stored client secret is a copied house key that works until someone changes the locks. OIDC is a visitor badge printed at reception for one visit, checked against the guest list, and useless the next day.

त्वरित जाँच: Why is OIDC federation preferred over storing a client secret in GitHub?

• It makes deployments run faster
• It removes the need for RBAC roles
• It only works with Bicep
• No long-lived secret is stored; each run gets a short-lived token scoped by a trust rule