Identity Federation Across AWS, Azure, and GCP

By Khimananda Oli | Last reviewed: August 2026

Managing separate credentials for every cloud environment is a security liability and an operational bottleneck. Identity federation across AWS, Azure, and GCP solves this by anchoring authentication to a single source of truth while delegating authorization to each platform’s native IAM. Instead of syncing users or managing static keys, you establish trust relationships that allow your corporate IdP to vouch for identities everywhere. This guide covers the practical architecture, protocol selection, and policy mapping required to build a unified, audit-ready multi-cloud identity plane.

How does identity federation across AWS, Azure, and GCP actually work?

Federation replaces the "create user in cloud" model with a "trust but verify" handshake. When an engineer needs access, they authenticate against your central Identity Provider (IdP). The IdP issues a signed token (OIDC JWT or SAML assertion) containing claims about who they are and what groups they belong to. The cloud provider validates this signature against a pre-configured trust relationship and maps the token's claims to a local IAM role or permission set.

This decoupling is critical for compliance. In my work preparing teams for SOC 2 and ISO 27001 audits, federation provides a clean separation of concerns: the IdP handles authentication strength (MFA, device posture), while the cloud handles resource authorization. Auditors can verify access reviews in one place rather than chasing screenshots from three different consoles. For a deeper look at how this fits into broader infrastructure governance, see our guide on AWS IAM best practices for least-privilege access.

The mechanism differs slightly per provider. AWS uses IAM Identity Center (formerly SSO) as an abstraction layer that syncs users/groups via SCIM and assigns Permission Sets. Azure, when using Entra ID, treats the cloud as a first-party application with native integration. GCP offers both Cloud IAM federation for human users and Workload Identity Federation for service-to-service access. Understanding these distinctions prevents the common mistake of trying to force identical configurations across all three platforms.

Which protocol should you choose: OIDC vs SAML for multi-cloud?

Protocol selection determines your operational overhead and security ceiling. While both achieve federation, they serve different use cases in 2026.

• OIDC (OpenID Connect): Preferred for modern workloads, CI/CD pipelines, and service-to-service communication. It uses JSON Web Tokens (JWTs) that are lightweight, easily parsed by applications, and support fine-grained claims mapping. AWS IAM Identity Center and GCP Workload Identity Federation natively prefer OIDC.
• SAML 2.0: Still necessary for legacy enterprise applications and certain GCP human-user federation scenarios. XML-based assertions are heavier but widely supported by older IdPs. SAML remains the fallback when OIDC isn't available.
• SCIM (System for Cross-domain Identity Management): Not an authentication protocol but essential for provisioning. SCIM automates user/group synchronization between your IdP and cloud directories. Without SCIM, you're manually managing assignments, which defeats the purpose of federation.

In practice, I recommend OIDC as the default for any new deployment in 2026. Reserve SAML for specific legacy integrations or when your IdP lacks OIDC support for a particular cloud. For service accounts and automation, always use OIDC-based workload identity federation to avoid long-lived credentials entirely. If you're building Kubernetes infrastructure across these clouds, our Kubernetes RBAC guide shows how to extend this federation model into cluster-level authorization.

How do you configure trust and role mapping in each cloud?

Trust configuration is where most federation projects stall. Each cloud requires explicit declaration of what tokens to accept and how to translate them into local permissions.

AWS IAM Identity Center setup

AWS abstracts federation through IAM Identity Center. You configure your IdP once, then assign Permission Sets to users/groups.

# Example: Terraform for AWS IAM Identity Center OIDC connection
resource "aws_ssoadmin_application" "oidc_app" {
  name               = "corporate-idp"
  application_provider_arn = "arn:aws:sso:::applicationProvider/customOIDC"
}

resource "aws_ssoadmin_trusted_token_issuer" "issuer" {
  application_arn      = aws_ssoadmin_application.oidc_app.application_arn
  name                 = "entra-id-issuer"
  trusted_token_issuer_configuration {
    oidc_jwt_configuration {
      claim_attribute_path       = "sub"
      identity_store_attribute_path = "userId"
      issuer_url                 = "https://login.microsoftonline.com/{tenant-id}/v2.0"
      jwks_keys_uri              = "https://login.microsoftonline.com/{tenant-id}/discovery/v2.0/keys"
    }
  }
}

After establishing trust, create Permission Sets that map to AWS managed or custom policies. Assign these sets to synced groups, not individual users, to maintain scalability. Enable MFA enforcement at the Identity Center level to satisfy compliance requirements without configuring it per-account.

Azure Entra ID native integration

If your IdP is Entra ID, Azure federation is implicit. For external IdPs, configure an Enterprise Application with SAML or OIDC. The critical step is setting up User Provisioning via SCIM to keep group memberships current. Azure's Conditional Access Policies then layer on top of federation to enforce device compliance, location restrictions, and risk-based sign-in requirements.

GCP Cloud IAM and Workload Identity

GCP separates human and workload federation. For humans, configure SAML SSO at the Organization or Folder level. For workloads, use Workload Identity Federation to map external OIDC tokens directly to Google Service Accounts without exporting keys.

# gcloud: Create workload identity pool for GitHub Actions
gcloud iam workload-identity-pools create "github-pool" \
  --project="my-project" \
  --location="global" \
  --display-name="GitHub Actions Pool"

# Add OIDC provider
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
  --project="my-project" \
  --location="global" \
  --workload-identity-pool="github-pool" \
  --display-name="GitHub Provider" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --issuer-uri="https://token.actions.githubusercontent.com"

This configuration allows GitHub Actions workflows to impersonate GCP service accounts based on repository and branch claims, eliminating static JSON key files entirely. For teams managing observability across these environments, understanding metrics, logs, and traces compared helps ensure your federated identity events are properly captured in each cloud's audit trail.

What are the common pitfalls and security risks in federation?

Federation reduces credential sprawl but introduces new attack surfaces if misconfigured. These are the failures I see repeatedly in production audits.

1. Overly permissive claim mapping: Mapping broad IdP groups to admin roles violates least privilege. Always map to the most specific attribute possible (e.g., department=engineering AND team=platform rather than just group=staff).
2. Missing session duration limits: Default token lifetimes may be too long for sensitive environments. Configure session timeouts in both the IdP and cloud-side Permission Sets to match your risk tolerance.
3. Ignoring deprovisioning latency: SCIM sync isn't instantaneous. A terminated employee might retain access for minutes to hours. Implement emergency revocation procedures and monitor for post-termination activity.
4. Static fallback credentials: Keeping break-glass accounts or static API keys "just in case" undermines federation. Rotate and vault these separately, alert on their use, and test your recovery path regularly.
5. Inconsistent MFA enforcement: Relying solely on IdP MFA without cloud-side Conditional Access or Session Policies leaves gaps. Defense-in-depth requires verification at both layers.

For Nepal-based teams serving global clients, remember that data residency requirements may affect where your IdP stores authentication logs. Ensure your federation design accounts for cross-border data flows if your IdP is hosted outside Nepal while accessing resources in specific regions.

How do you automate and govern federated access at scale?

Manual federation setup doesn't survive team growth. Treat your identity configuration as code and integrate it into your existing IaC workflows.

• Terraform/OpenTofu: Define IdP applications, cloud trust policies, and role mappings in version-controlled modules. Use separate state files per cloud to limit blast radius.
• Policy-as-Code: Use OPA/Rego or cloud-native policy engines (AWS SCPs, Azure Policy, GCP Org Policies) to enforce guardrails. Prevent creation of overly permissive Permission Sets or unauthorized trust relationships.
• Access Reviews: Automate quarterly access certifications. Tools like Vanta, Drata, or native cloud governance suites can pull assignment data and route review tasks to managers. This is non-negotiable for SOC 2 Type II.
• Monitoring: Forward authentication logs to your SIEM. Alert on anomalous patterns: impossible travel, new device enrollments, privilege escalation attempts, and failed federation handshakes.

Start with a pilot group before rolling out organization-wide. Validate that deprovisioning works end-to-end by terminating a test account and verifying access loss across all clouds within your SLA. Document the emergency break-glass procedure and test it annually.

Implementing identity federation across AWS, Azure, and GCP

Successful identity federation across AWS, Azure, and GCP requires treating identity as infrastructure, not an afterthought. Begin by selecting OIDC as your primary protocol, configuring trust relationships via IaC, and enforcing least-privilege mapping from day one. Integrate access reviews into your compliance cadence and monitor authentication events alongside your application telemetry. The upfront investment eliminates credential sprawl, simplifies audits, and gives your team a secure foundation for multi-cloud operations. If you need help designing or auditing your federation architecture, reach out to discuss your specific requirements.