OIDC-based Azure authentication in pipelines

Overview

OIDC-based Azure authentication lets CI/CD pipelines authenticate to Azure without storing long-lived client secrets. Instead of keeping a password in GitHub Actions secrets or an Azure DevOps service connection, the pipeline receives a short-lived OpenID Connect token from the CI/CD platform. Microsoft Entra ID trusts that token through a federated credential and exchanges it for an Azure access token.

This pattern is commonly called workload identity federation. It is now the preferred direction for many Azure pipeline integrations because it reduces secret leakage risk and makes authentication more tied to the pipeline's identity, repository, branch, environment, or service connection.

For interviews, candidates should be able to explain the trust flow, why it is safer than client secrets, how GitHub Actions and Azure DevOps differ, what claims are trusted, why id-token: write matters in GitHub Actions, how service connections work in Azure DevOps, and how to apply least privilege.

Core Concepts

The Problem with Long-Lived Secrets

Traditional pipeline authentication often uses:

• Service principal client secrets.
• Publish profiles.
• Stored passwords.
• Long-lived certificates.

These create risks:

• Secrets can be copied from logs, variables, or developer machines.
• Rotation is often forgotten.
• A leaked secret can be used outside the pipeline.
• The secret may have broad Azure permissions.
• Pull-request or third-party action compromise can expose credentials.

OIDC reduces these risks by replacing stored deployment passwords with short-lived tokens and explicit trust rules.

OIDC

OpenID Connect is an identity layer on top of OAuth 2.0. In a CI/CD context, the pipeline platform acts as an issuer of identity tokens for jobs.

The token contains claims such as:

• Issuer.
• Subject.
• Audience.
• Repository or project information.
• Branch, tag, environment, or service connection context.
• Job identity details.

Microsoft Entra ID validates the token against a configured federated credential before issuing Azure tokens.

Workload Identity Federation

Workload identity federation creates a trust relationship between Microsoft Entra ID and an external workload identity provider such as GitHub Actions or Azure DevOps.

The basic flow:

1. A pipeline job starts.
2. The CI/CD provider issues an OIDC token for the job.
3. Azure login or a service connection presents that token to Microsoft Entra ID.
4. Microsoft Entra ID validates issuer, subject, and audience.
5. Microsoft Entra ID returns a short-lived access token.
6. The pipeline uses that token to deploy Azure resources.

No client secret is stored in the pipeline.

Federated Credential

A federated credential is configured on a Microsoft Entra application or user-assigned managed identity. It specifies which external token should be trusted.

Important fields include:

• Issuer.
• Subject.
• Audience.
• Name.

The subject should be as narrow as practical. For example, trust only a specific repository branch or production environment rather than every workflow in an organization.

GitHub Actions OIDC Flow

For GitHub Actions, the workflow must request permission to obtain an OIDC token:

permissions:
  id-token: write
  contents: read

Then use Azure Login:

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

The client ID, tenant ID, and subscription ID identify the trusted application or managed identity. They are identifiers, not secrets.

GitHub Subject Scoping

GitHub OIDC subject claims can be scoped to repository, branch, tag, pull request, or environment patterns.

Examples of intent:

Only main branch can deploy dev.
Only a protected production environment can deploy prod.
Pull requests cannot get production Azure tokens.
Release tags can deploy staging.

Use GitHub environments with required reviewers for production. The OIDC trust should align with the protected environment or branch policy.

Azure DevOps Workload Identity Federation

Azure DevOps uses Azure Resource Manager service connections for Azure deployments. For new service connections, workload identity federation is recommended over service principal secrets.

The service connection represents:

• The Azure target scope.
• The identity used by the pipeline.
• The authentication method.
• Which pipelines are authorized to use it.

Avoid granting access to all pipelines by default. Authorize only the pipelines that need the connection.

App Registration Versus Managed Identity

Federation can use a Microsoft Entra app registration or a user-assigned managed identity.

Use an app registration when:

• You want a pipeline identity not tied to an Azure resource.
• Your organization already manages deployment identities this way.
• You need broad compatibility.

Use a user-assigned managed identity when:

• You want an Azure-managed workload identity.
• A platform team owns identity lifecycle in Azure.
• You want to avoid app registration creation permissions for project teams.

Both still need least-privilege RBAC.

RBAC Scope

The federated identity only authenticates the pipeline. Authorization still comes from Azure RBAC.

Scope permissions as narrowly as practical:

• Resource group for app team deployments.
• Subscription only when resources across many groups are needed.
• Management group only for governance pipelines.
• Specific roles instead of Owner when possible.

Common deployment roles may include Contributor plus specific role-assignment permissions when needed. Avoid Owner unless the pipeline truly needs to manage access.

Separate Identities by Environment

Use different identities or service connections for dev, test, and production.

Benefits:

• Pull requests cannot accidentally deploy production.
• Compromising a lower environment does not grant production access.
• Audit logs show which environment identity acted.
• Production can require stricter approvals.
• RBAC can be tailored per environment.

One identity for everything is convenient until it becomes a blast-radius problem.

Least Privilege

A pipeline identity should have only the permissions needed for its job.

Examples:

• App deployment identity can deploy to one App Service.
• Infrastructure identity can deploy to one resource group.
• Read-only validation identity can run what-if.
• Production identity can be used only from protected branches or environments.

Avoid assigning broad permissions just to make a pipeline pass. Fix the missing permission deliberately.

Token Lifetime and Replay Risk

OIDC tokens and Azure access tokens are short-lived. This reduces risk but does not make pipelines automatically safe.

Still protect:

• Workflow files.
• Branch policies.
• Third-party actions.
• Self-hosted runners.
• Logs.
• Environment approvals.
• Federated credential subject patterns.

If an attacker can modify trusted pipeline YAML on a trusted branch, they may be able to use the federated identity.

Pull Requests from Forks

Treat pull requests from forks and untrusted contributors carefully. They should not receive deployment permissions or access to production environments.

Safe pattern:

• Run build and tests with minimal permissions.
• Do not grant Azure tokens.
• Do not expose environment secrets.
• Require merge to protected branch before deployment.

OIDC does not remove the need for source control trust boundaries.

Environments and Approvals

OIDC trust should align with deployment gates.

For GitHub Actions:

• Use protected environments for production.
• Require reviewers.
• Scope federated credentials to the environment where practical.

For Azure DevOps:

• Use environment checks and approvals.
• Restrict service connection use.
• Use separate service connections per environment.

The authentication policy should match the release policy.

Auditing

Audit both sides:

• Pipeline run history.
• Environment approvals.
• Service connection usage.
• Microsoft Entra sign-in logs.
• Azure Activity Log deployment operations.
• Role assignment changes.
• Federated credential changes.

During an incident, you need to know which pipeline identity changed which resource from which run.

Secretless Does Not Mean Riskless

OIDC removes stored secrets, but it does not secure bad deployment design.

Risks remain:

• Overbroad Azure RBAC.
• Unprotected production branch.
• Unsafe third-party action.
• Compromised self-hosted runner.
• Federated credential with overly broad subject.
• Pipeline YAML injection.
• No approval on production environment.

Treat pipeline code as privileged production code.

Common Mistakes

• Thinking AZURE_CLIENT_ID is a secret.
• Granting Contributor at subscription scope for every pipeline.
• Using one identity for every environment.
• Trusting all branches or all repositories.
• Allowing all pipelines to use an Azure DevOps service connection.
• Giving pull-request workflows deployment permissions.
• Storing a client secret "just in case" after enabling OIDC.
• Not auditing federated credential changes.
• Using third-party actions without review.
• Forgetting that RBAC controls authorization after authentication.

Best Practices

• Prefer OIDC or workload identity federation over long-lived secrets.
• Scope federated credentials narrowly.
• Use separate identities per environment.
• Use protected branches and environments.
• Assign least-privilege Azure roles.
• Avoid granting service connections to all pipelines.
• Keep pipeline YAML reviewed and protected.
• Pin or review third-party actions.
• Audit deployments and identity use.
• Rotate away old secrets after migration.