Skip to main content

Service Principal and Federated Identity Credential

The mechanism of application authentication and authorization in Azure (Microsoft Entra ID) is crucial for achieving automation while maintaining security. This document explains the basic concepts of Service Principal and the more secure authentication method, Federated Identity Credential (Workload Identity Federation).

What is a Service Principal?​

While a "user" identity in Azure is a User Principal, an identity used by applications or services to access Azure resources is called a Service Principal.

Relationship between App Registration and Service Principal​

In Microsoft Entra ID (formerly Azure AD), the definition of an application and its actual identity are separated as follows:

  1. Application Object (App Registration):

    • The definition (blueprint) of the application.
    • Has a globally unique "Application ID (Client ID)" within the tenant.
    • Defines required permissions, redirect URIs, etc.

  2. Service Principal Object:

    • The instance (entity) of the application actually running within a specific tenant.
    • Azure RBAC (Role-Based Access Control) assigns permissions to this Service Principal.

Types of Credentials​

For a Service Principal to authenticate, one of the following credentials is required:

  • Password (Client Secret): A string secret. Requires management of expiration and leakage risks.
  • Certificate: Uses a public key certificate. More secure than secrets but requires certificate management.
  • Federated Identity Credential: Authentication based on a trust relationship with an external identity provider, described later.

Managed Identity​

Managed Identity is provided to simplify the management of Service Principals (especially secret management).

  • Mechanism: Automatically creates a Service Principal for Azure resources (VM, App Service, Functions, etc.), and the Azure platform handles credential rotation behind the scenes.
  • Benefits: Developers do not need to manage secrets at all. There is no need to embed credentials in the code.
  • Types:
    • System-assigned: An ID that shares the lifecycle with the resource. The ID is deleted when the resource is deleted.
    • User-assigned: An ID that can be created independently. Can be shared across multiple resources.

For access between Azure resources (e.g., accessing SQL Database from App Service), it is recommended to use Managed Identity whenever possible.

Federated Identity Credential (Workload Identity Federation)​

When accessing Azure from systems outside Azure (GitHub Actions, Kubernetes, GitLab CI, etc.), traditionally, you had to issue a Client Secret for a Service Principal and store it in the external system. However, this comes with the risk of secret leakage.

Using Workload Identity Federation, you can obtain access tokens based on a trust relationship with an external Identity Provider (IdP) without managing secrets (passwords or certificates).

Mechanism (OIDC)​

Authentication is performed using the OpenID Connect (OIDC) protocol in the following flow:

  1. External IdP (e.g., GitHub) issues an OIDC token proving the identity of the current job or workload.
  2. The external system sends this OIDC token to Azure AD.
  3. Azure AD validates the token against the pre-configured Federated Identity Credential settings (Issuer, Subject, etc.).
  4. If validation succeeds, Azure AD returns an access token for the Service Principal.
  5. The external system uses this access token to operate Azure resources.

Example Use Case in GitHub Actions​

When deploying to Azure from GitHub Actions, it is currently a best practice to use OIDC with the azure/login action.

1. Configuration on Azure​

Add a Federated Identity Credential to the Service Principal.

  • Issuer: https://token.actions.githubusercontent.com
  • Subject Identifier: repo:<org>/<repo>:ref:refs/heads/<branch> (e.g., repo:my-org/my-repo:ref:refs/heads/main)

2. GitHub Actions Workflow​

permissions:
  id-token: write # Required to request the OIDC token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          # client-secret is NOT required!

Benefits​

  • Secretless: No long-lived secrets (passwords) exist, eliminating leakage risks.
  • Granular Scope Control: Allows fine-grained control, such as allowing access only from specific repositories, branches, or environments.
  • Reduced Management Cost: No need for secret rotation tasks.

Summary​

  • Service Principal: Identity for applications.
  • Managed Identity: Service Principal for Azure resources that requires no secret management. Ideal for communication within Azure.
  • Federated Identity Credential: Secretless authentication method from external systems (like GitHub Actions) to Azure. Ideal for CI/CD pipelines.

To improve security, it is recommended to use Managed Identity or Workload Identity Federation whenever possible and avoid using Client Secrets.