Entra ID Workload Identity Federation: Seamless Cross-Cloud Machine Authentication

Date: 2026-08-17

Discover how Entra ID Workload Identity Federation simplifies secure, secretless cross-cloud machine authentication by eliminating static credentials.

Tags: ["Entra ID", "Workload Identity Federation", "Cross-Cloud", "Azure", "AWS"]

Cross-cloud integration increasingly challenges organizations to securely authenticate machine workloads across distinct identity boundaries. The explosion of cloud services—AWS, Azure, GCP—means workloads frequently need to communicate across different clouds, creating a complex web of identities and credentials to manage.

Microsoft’s Entra ID Workload Identity Federation (WIF) offers a modern, scalable answer to this challenge: it enables workloads in one cloud (or trust boundary) to authenticate to Azure resources without relying on static secrets. By leveraging token exchange based on trusted external identity providers, WIF drastically reduces the operational burden of credential management and enhances security posture.

In this post, we explore the problem WIF addresses, how it works under the hood, and a practical AWS-to-Azure example that demonstrates real-world usage. By the end, you’ll understand why eliminating static secrets is crucial for scalable, secure cross-cloud identity and how Entra ID WIF makes it possible.

Architecture Overview

┌───────────────────────────────┐
│      External Cloud Workload  │
├───────────────────────────────┤
│  • AWS EC2, Lambda, GCP Pods │
│  • Other Cloud Identity Token│
│    Issuers (IdPs)            │
└───────────────┬───────────────┘
                │ Obtain OIDC or SPIFFE token
                ↓
┌───────────────────────────────┐
│     Entra ID Workload Identity│
│          Federation           │
├───────────────────────────────┤
│  • Federated Credential Setup │
│  • Trust External IdPs        │
│  • Token Validation & Exchange│
│  • Service Principal or Managed│
│    Identity access control    │
└───────────────┬───────────────┘
                │ Issue Azure OAuth Access Token
                ↓
┌───────────────────────────────┐
│   Azure Resources & Services  │
├───────────────────────────────┤
│  • Azure Storage, APIs        │
│  • MS Graph, Custom APIs      │
│  • Access via Federated Token │
└───────────────────────────────┘

This flow depicts external cloud workloads obtaining identity tokens from their native identity providers (AWS STS, GCP Auth Server, SPIFFE), presenting these tokens to Entra ID, which verifies and exchanges them for Azure access tokens. Azure resources then accept these tokens to authorize requests — all without static secrets.

Entra ID – Deep Dive – Workload Identity Federation – Bonus

Diagram sourced from Journey Of The Geek

Key Technical Observations

Federated Trust Boundaries Enable Identity Control Autonomy — WIF lets each organization or cloud provider maintain control over their identity system while enabling cross-boundary workload authentication without replicating identities.
Elimination of Static Secrets Advances Security — Classic patterns use secrets (client secrets or certificates) stored in secrets managers. WIF replaces this with token exchanges, drastically reducing risk of credential leakage and operational complexity.
Support for Multiple Identity Types in Entra ID — Entra ID processes both application resource based service principals and managed identities (Azure’s equivalent to AWS IAM roles). This flexibility allows matching workload identity design to business needs.
Audience & Subject Validation Enforced in Federated Credentials — Configuration of federated credentials requires specifying issuer URLs (e.g., AWS STS), expected subject claims (like IAM role ARN), and audience strings. This prevents token misuse or replay attacks by binding tokens tightly to intended identities.
Lifecycle and Scale Considerations with Federated Credentials — Each managed identity or application registration can have up to 20 federated credentials; to address scale, a preview feature called flexible federated identity credentials supports expression-based subject matching.
Integration with Industry Standards like SPIFFE — WIF’s support for SPIFFE tokens extends workload federation beyond cloud vendors, enabling standard-based workload identity across heterogeneous environments.

How It Works: Under the Hood of Entra ID Workload Identity Federation

Defining the Problem: Cross-Boundary Workload Authentication

Organizations have long struggled with how to allow non-human workloads in one security domain to securely access resources in another without proliferating credentials. Cloud adoption amplified this with workloads scattered across AWS, Azure, and Google Cloud.

Prior common patterns required workloads to hold static secrets often managed by secrets managers, complicating rotation, auditing, and increasing risk.

WIF’s Core Model: Token Exchange Federation

Entra ID WIF removes the static secret by trusting tokens issued by an external identity provider. The workload:

Obtains a short-lived token from its native IdP (e.g., AWS STS via AssumeRole).
Presents that token to Entra ID’s token endpoint.
Entra ID verifies the token’s cryptographic signature and claims using public keys fetched dynamically from the external IdP metadata endpoint.
Upon successful verification, Entra ID issues an OAuth2 access token scoped for the requested Azure resource.

From Entra’s standpoint, the workload’s identity maps to an Entra service principal or managed identity configured with a federated credential pointing to that external IdP and trusted subject.

Identity Configuration in Entra ID

Service Principals: In Azure, workloads are represented as service principals tied to either application registrations or managed identities.
Federated Credentials: Federated credentials link these service principals to trusted external tokens by specifying issuer URLs and subjects (usually IAM role ARNs or SPIFFE IDs), plus audience constraints.

Example: AWS EC2 to Azure Storage Access via WIF

AWS Side: Enable outbound federation on the AWS account STS, allowing the issuance of tokens to external relying parties (i.e., Entra ID).
IAM Policy: Authorize the EC2 instance’s IAM role to call sts:GetWebIdentityToken with required audience.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "sts:IdentityTokenAudience": "api://AzureADTokenExchange/6c80de31-d5e4-4029-XXXX-XXXXXXXXXXXX"
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                },
                "StringEquals": {
                    "sts:SigningAlgorithm": "RS256"
                }
            }
        }
    ]
}

Azure Side: Create a User-Assigned Managed Identity (UMI) and configure it with a federated credential tied to the AWS STS issuer URL and the EC2 role ARN.
Token Exchange Flow:
The EC2 instance requests a web identity token from AWS STS scoped for the tenant audience.
It calls Entra ID’s token endpoint to exchange this AWS-issued token for an Azure access token using the ClientAssertionCredential in Python.
Entra ID validates the AWS token and issues the access token.
The application uses this token to access an Azure Storage Blob.

Code Snippet

from azure.identity import ClientAssertionCredential
from azure.storage.blob import BlobServiceClient
from dotenv import load_dotenv

load_dotenv(override=True)

TENANT_ID = os.getenv("ENTRA_TENANT_ID")
UMI_CLIENT_ID = os.getenv("AZURE_UMI_CLIENT_ID")
BLOB_ACCOUNT_URL = os.getenv("AZURE_BLOB_ACCOUNT_URL")
BLOB_CONTAINER_NAME = os.getenv("AZURE_BLOB_CONTAINER_NAME")
BLOB_NAME = os.getenv("AZURE_BLOB_NAME")

def get_aws_sts_token() -> str:
    sts_client = boto3.client('sts', region_name='us-east-1')
    response = sts_client.get_web_identity_token(
        Audience=[f"api://AzureADTokenExchange/{TENANT_ID}"],
        DurationSeconds=300,
        SigningAlgorithm='RS256'
    )
    return response["WebIdentityToken"]

credential = ClientAssertionCredential(
    tenant_id=TENANT_ID,
    client_id=UMI_CLIENT_ID,
    func=get_aws_sts_token,
)

blob_service_client = BlobServiceClient(account_url=BLOB_ACCOUNT_URL, credential=credential)
blob_client = blob_service_client.get_blob_client(container=BLOB_CONTAINER_NAME, blob=BLOB_NAME)
blob_data = blob_client.download_blob().readall()
print(blob_data.decode("utf-8"))

Why This Matters

No static secret needs to be stored or rotated between AWS and Azure.
The AWS-assigned temporary token proves identity upon every request.
Entra ID enforces strict validation ensuring only authorized tokens receive access tokens.
Workloads gain seamless, scalable access to Azure resources leveraging native cloud identity mechanisms.

Quick Tips & Tricks

Use Managed Identities for Simplicity — When your workload only accesses Azure resources, prefer user-assigned managed identities. This keeps resource relationships and permissions clear within Azure subscriptions.
Application Registrations for Multi-API Access — Use application resources if your workload will call Microsoft Graph or other APIs beyond Azure data services for improved visibility.
Tightly Scope Audience and Subject Claims — Ensure the federated credential’s audience string and subject identifiers are precise to reduce injection risk.
Leverage Flexible Federated Identity Credentials at Scale — If you have many workloads sharing an identity, use the preview flexible federated identity credentials feature to match subjects by regex/expression instead of individual subject entries.
Monitor and Audit Federated Tokens Usage — Even with no static credentials, regularly audit token exchanges and access patterns within Entra and your cloud provider logs.
Stay Aware of Premium Features — Advanced features like conditional access and privileged access reviews require licenses but can provide value for protecting your highest-risk workload identities.

Conclusion

Entra ID Workload Identity Federation is a vital evolution in how enterprises manage cross-cloud workload authentication. By eliminating static secrets and enabling trust through token exchange, it simplifies operational complexity and strengthens security for hybrid and multi-cloud architectures.

The pattern demonstrated for AWS EC2 instances accessing Azure Storage is just one example of the broader potential — any workload capable of obtaining an identity token from a trusted external IdP can use WIF to seamlessly authenticate to Azure resources.

As cloud environments continue growing in complexity and scale, adopting identity federation and secretless authentication will become essential. Microsoft’s Entra ID WIF sets a strong foundation for this future, providing the tooling and standards alignment needed to securely federate workload identities beyond organizational borders.