Identity Federation Across AWS, Azure, and GCP

By Kokil Thapa | Last reviewed: September 2026

Identity federation across AWS, Azure, and GCP is how you let humans, services, and CI jobs prove who they are without copying long-lived access keys into every repo. On a production Laravel app that talks to S3, Azure Blob, and Cloud Storage, static credentials rot slowly, leak quietly, and break audits. Federation replaces them with trust relationships: your corporate IdP or one cloud's OIDC issuer vouches for a caller, and the target cloud issues short-lived credentials. This guide maps the models, config paths, and production traps I've seen while wiring workload identity federation without long-lived keys on real client stacks.

What is identity federation across AWS, Azure, and GCP?

Identity federation means an external party authenticates a subject, and a cloud platform accepts that proof to grant access. AWS calls federated principals IAM roles fed by SAML 2.0 or OIDC. Azure maps them through Microsoft Entra ID (formerly Azure AD) and federated credentials. GCP uses Workload Identity Federation to trust external OIDC or SAML issuers.

The pattern is the same on every cloud: establish trust, map claims to a local identity, issue scoped credentials. What differs is naming, default session length, and how tightly each vendor couples to its own IdP. For teams running PHP on GCP vs AWS vs Azure for PHP workloads, federation is often the first security fix after migration.

Three federation layers matter in practice:

• Human federation — staff sign in via SAML/OIDC; clouds map groups to roles. Common for console and CLI access.
• Workload federation — GitHub Actions, GitLab CI, or a VM identity exchanges an OIDC token for cloud credentials. No keys in git.
• Cross-cloud federation — a service in AWS assumes a role in GCP via WIF, or Azure trusts AWS OIDC for pipeline deploys. Harder, but avoids duplicate secret stores.

On legal-tech portals I've maintained, document uploads hit object storage in one cloud while the app runs elsewhere. Federation keeps those integrations auditable. See our Mijar Law Associates client portal class of systems where RBAC and external storage must align.

How does OIDC workload identity federation work without long-lived keys?

OIDC federation is the default for CI/CD in 2026. Your pipeline requests a JWT from its platform issuer. The target cloud validates signature, audience, and subject, then returns temporary credentials scoped to one role.

AWS documents this as web identity federation via AssumeRoleWithWebIdentity. GCP packages it as Workload Identity Federation. Azure exposes federated identity credentials on app registrations and managed identities, described in Microsoft's workload identity federation guide.

AWS: GitHub Actions to IAM role

Create an OIDC provider, then trust it from a role:

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

# Trust policy snippet (attach to role)
{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:org/app:ref:refs/heads/main"
    }
  }
}

In GitHub Actions, request the role with aws-actions/configure-aws-credentials. Session tokens expire in one hour by default. Rotate nothing manually.

GCP: GitLab CI to service account

Define a workload identity pool and provider, then bind IAM:

gcloud iam workload-identity-pools create "gitlab-pool" \
  --location="global" \
  --display-name="GitLab CI Pool"

gcloud iam workload-identity-pools providers create-oidc "gitlab-provider" \
  --location="global" \
  --workload-identity-pool="gitlab-pool" \
  --issuer-uri="https://gitlab.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.project_path=assertion.project_path"

# Allow GitLab project to impersonate SA
gcloud iam service-accounts add-iam-policy-binding \
  SA_NAME@PROJECT.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/gitlab-pool/attribute.project_path/mygroup/myapp"

Your pipeline calls gcloud auth login --cred-file or uses the google-github-actions/auth action pattern. Tokens last minutes to hours depending on config.

Azure: federated credential on managed identity

az identity federated-credential create \
  --name "github-main" \
  --identity-name "deploy-uami" \
  --resource-group "prod-rg" \
  --issuer "https://token.actions.githubusercontent.com" \
  --subject "repo:org/app:ref:refs/heads/main" \
  --audiences "api://AzureADTokenExchange"

Azure DevOps and GitHub both support this path. Pair it with Azure Key Vault secrets in pipelines so deploy scripts never touch plaintext secrets.

How do you configure cross-cloud identity federation step by step?

Cross-cloud federation means Cloud A trusts Cloud B's OIDC issuer, or both trust one corporate IdP. Start simple: one IdP, three cloud apps, group-based role mapping. Add cross-cloud only when a workload in one vendor must call APIs in another without a shared secret.

1. Inventory identities — list humans, CI pipelines, VMs, and Lambda/Cloud Functions that currently use static keys. Use a password and secret hygiene checklist to flag embedded credentials in env files.
2. Pick a canonical IdP — Microsoft Entra ID, Okta, or Google Workspace for staff. For machines, prefer each CI platform's native OIDC issuer over inventing your own.
3. Configure SAML/OIDC apps per cloud — AWS IAM Identity Center, Entra enterprise apps, GCP Workforce Identity Federation for human access. See AWS IAM Identity Center documentation for the AWS side.
4. Map groups to roles — never map individual users at scale. Use groups or roles claims consistently.
5. Enable workload pools — WIF on GCP, OIDC providers on AWS, federated credentials on Azure for each pipeline.
6. Remove static keys — delete access keys after parity testing. Monitor CloudTrail, Azure Activity Log, and GCP Audit Logs for AssumeRole failures.
7. Document break-glass — one emergency local admin per cloud, stored offline, with MFA enforced.

SAML for enterprise staff access

SAML 2.0 remains the enterprise default for browser SSO. Entra ID publishes metadata XML; AWS IAM Identity Center consumes it; GCP Workforce Identity Federation accepts third-party IdP SAML assertions. Attribute mapping must align:

# AWS Identity Center attribute mapping (conceptual)
Subject      = user.userprincipalname
email        = user.mail
groups       = user.groups

Mismatch on groups is the top reason federated users land in the wrong permission set. Test with a single pilot group before cutover.

Cross-cloud: AWS Lambda calling GCP APIs

Configure GCP WIF to trust AWS STS as an OIDC issuer (via a custom OIDC wrapper) or use a small token-exchange service. In practice, many teams run a thin API gateway layer in one cloud that holds federation logic, so application code stays dumb HTTP.

On a production Laravel application, I've used this pattern: the app runs on AWS EC2 with an instance profile; GCP access goes through WIF from GitLab CI for deploy-time tasks only. Runtime cross-cloud calls route through signed internal APIs instead of chaining federation twice.

Which identity federation model should you choose for multi-cloud apps?

Pick the model that matches your caller type and audit requirements. The table below compares what each cloud offers in 2026 for common scenarios.

For PHP and Laravel teams choosing a primary cloud, read AWS vs Azure vs Google Cloud in 2026 first. Federation complexity rises with vendor count, not language. A single-cloud app with WIF beats a tri-cloud mesh nobody can debug.

Budget matters too. Federation itself is cheap; misconfigured roles are expensive. Nepali startups often spread workloads across vendors for cost — see budgeting AWS and Azure in NPR — but identity should stay centralized even when compute is split.

Secret storage still has a place. Federation handles authentication; AWS Secrets Manager and Azure Key Vault hold database passwords and third-party API keys that no IdP should issue. Encrypt those with KMS — our AWS KMS envelope encryption guide covers the pattern.

What are common identity federation mistakes in production?

These failures show up on every audit and every 2 a.m. deploy page.

Over-broad trust policies

A trust policy that says StringLike: sub = repo:org/* lets any repository in the org assume production roles. Scope to branch and environment: repo:org/app:environment:production on GitHub, or GitLab protected branches only.

Mixing human and workload trust

Do not attach CI federation to the same role developers use for console access. Split deploy-role-prod from developer-readonly. I've seen a pipeline compromise become a full account takeover when those roles merged.

Ignoring token audience and issuer drift

CI platforms rotate OIDC thumbprints and issuer URLs. Pin AWS thumbprints, but monitor provider health. A failed deploy after a GitHub infrastructure change is often a stale OIDC provider config.

Leaving break-glass keys in .env

Federation does not remove Laravel .env secrets for MySQL or Redis. It removes cloud vendor keys. After enabling WIF, grep repos for AKIA, azure_client_secret, and GCP JSON key files. Store remaining secrets in vaults, not git.

Skipping audit correlation

Each cloud logs federation differently. Ship CloudTrail, Azure sign-in logs, and GCP audit logs to one SIEM or at least one S3 bucket. Correlate by subject claim and pipeline run ID.

Infrastructure-as-code helps keep trust policies reviewable. Terraform modules in deploy the same app to AWS and Azure with Terraform let you diff IAM changes in pull requests. Pair with Azure DevOps or GitLab CI pipelines that assume federated roles — never embed keys in YAML.

For user-facing auth on apps — logins, not cloud IAM — keep concerns separate. AWS Cognito for user authentication serves application users; Entra ID B2C or Laravel Sanctum serves others. Cloud federation governs who can deploy and operate infrastructure, not who buys flowers or books a notary slot.

Teams building booking platforms like Adventure Third Pole Trek often start on one VPS, then split storage to object storage when uploads grow. Federation makes that split safe. Our enterprise application development and custom software development engagements typically include an identity review before any multi-cloud cutover.

Ongoing ops belong in runbooks. After federation goes live, schedule quarterly trust-policy reviews with support and maintenance coverage. Server hardening — IMDSv2 on AWS, managed identities on Azure — pairs with Linux system administration baselines.

Key Takeaways

• Identity federation across AWS, Azure, and GCP replaces long-lived keys with OIDC or SAML trust and short-lived STS tokens.
• Use corporate IdP federation for staff, native workload identity for CI, and instance profiles or managed identities for VMs — never mix deploy and human roles.
• Scope OIDC trust policies to repository, branch, and environment; audit CloudTrail, Azure Activity Log, and GCP Audit Logs after cutover.
• Keep application user auth (Sanctum, Cognito) separate from cloud IAM federation; they solve different problems.
• Store database and API secrets in Secrets Manager or Key Vault; federation does not eliminate all secrets, only cloud vendor keys.
• Start single-cloud WIF, add cross-cloud brokers only when needed, and codify IAM in Terraform pull requests.

People Also Ask

What is the difference between SAML and OIDC for cloud federation?

SAML 2.0 uses XML assertions and browser POST flows; it dominates enterprise staff SSO. OIDC uses JSON Web Tokens and fits CI pipelines, mobile apps, and service-to-service calls. Most 2026 architectures use SAML for humans and OIDC for machines.

Can one identity provider federate to AWS, Azure, and GCP at once?

Yes. Microsoft Entra ID, Okta, and Google Workspace all publish SAML and OIDC metadata that each cloud consumes. Map IdP groups to cloud-specific roles in IAM Identity Center, Entra app roles, and GCP Workforce Identity Federation respectively.

Do I still need service account keys after enabling workload identity federation?

No for CI and native compute identities. Delete GCP JSON keys, AWS access keys, and Azure client secrets once federated paths are tested. Keep break-glass credentials offline and rotate them on a fixed schedule separate from federation tokens.

How does identity federation affect Laravel deployments on multiple clouds?

Laravel apps keep using .env for app secrets but should obtain cloud storage and queue credentials from instance metadata or WIF at runtime. Deploy pipelines assume federated roles to run migrations and sync assets without storing vendor keys in GitLab or GitHub.

Ship multi-cloud identity federation with confidence

Identity federation across AWS, Azure, and GCP is not a one-time checkbox. It is an operating model: central IdP trust, scoped workload pools, no static keys in repos, and audit logs you actually read. Start with the pipeline that deploys your app, then expand to staff SSO and cross-cloud APIs only where business logic demands it.

If you are planning a multi-cloud cutover or cleaning up leaked cloud keys on a live system, contact us for a practical federation review. You can also browse the portfolio for examples of production apps that run secure document and booking workflows, or read more on the blog about cloud architecture for PHP teams.