---
source_url: "https://cloudtoolstack.com/learn/multi-cloud-identity-federation-patterns?utm_source=openai"
title: "Identity Federation Patterns | CloudToolStack"
mirrored_at: 2026-08-04T13:03:48.131Z
host: cloudtoolstack.com
cited_in_42a: true
mirror_canonical: "https://index.42a.ai/cloudtoolstack.com/learn/multi-cloud-identity-federation-patterns__q__utm_source_openai"
---

> **Original source:** https://cloudtoolstack.com/learn/multi-cloud-identity-federation-patterns?utm_source=openai

## Identity Federation Across Clouds

Identity federation allows users to authenticate once with a central identity provider (IdP) and access resources across multiple cloud providers without separate credentials for each. This eliminates credential sprawl, simplifies access management, and provides a single point for enforcing security policies like MFA, conditional access, and session management.

Federation uses industry standards: SAML 2.0 for web-based SSO, OIDC (OpenID Connect) for modern applications and workload identity, and OAuth 2.0 for API authorization. Each cloud provider supports these standards but with different configuration approaches, trust models, and terminology.

This guide covers SAML and OIDC federation patterns, cross-cloud workload identity (machine to machine), centralized identity with Entra ID/Okta/Google Workspace, and Terraform configurations for multi-cloud federation.

SAML vs OIDC

**SAML 2.0:** XML-based, mature, widely supported for enterprise SSO. Best for web console access and legacy applications. **OIDC:** JSON/JWT-based, modern, lightweight. Best for APIs, mobile apps, and workload identity federation. When possible, prefer OIDC over SAML for new implementations due to its simplicity and native support for machine-to-machine auth.

## SAML Federation to Each Cloud

SAML federation enables your corporate identity provider (Okta, Entra ID, Google Workspace, PingFederate) to authenticate users for cloud console access. Users sign in once at the IdP and are redirected to the cloud console with an assertion that maps them to roles.

### AWS SAML Federation

### Azure SAML Federation

### GCP SAML Federation

## OIDC Workload Identity Federation

Workload identity federation enables services running in one cloud to access resources in another cloud without long-lived credentials. Instead of storing cloud credentials as secrets, the workload exchanges its native identity token for short-lived credentials in the target cloud. This is the most secure pattern for cross-cloud service communication.

### GCP Workload Identity Federation from AWS

### AWS OIDC Federation from GCP/GitHub

## Cross-Cloud Trust Patterns

Pattern

Source

Target

Mechanism

AWS to GCP

AWS IAM Role

GCP Resources

GCP Workload Identity Federation (AWS provider)

GCP to AWS

GCP Service Account

AWS Resources

AWS OIDC provider (Google accounts.google.com)

Azure to AWS

Managed Identity

AWS Resources

AWS OIDC provider (Entra ID)

AWS to Azure

AWS IAM Role

Azure Resources

Entra ID federated credentials

GitHub to Any

GitHub Actions

All clouds

OIDC provider in each cloud

Kubernetes to Any

K8s Service Account

All clouds

OIDC (IRSA, Workload Identity, AAD WI)

## Terraform Multi-Cloud Federation

## Centralized Identity Architecture

The recommended architecture for multi-cloud identity uses a single authoritative IdP (Entra ID, Okta, Google Workspace) that federates to all cloud providers. This provides a single source of truth for identities, centralized MFA enforcement, unified access reviews, and consistent security policies.

### Architecture Recommendations

Component

Recommendation

Central IdP

Entra ID, Okta, or Google Workspace (one source of truth)

User federation

SAML for console access, OIDC for API access

Workload federation

OIDC workload identity (no long-lived credentials)

MFA

Enforce at IdP level (applies to all clouds)

Access reviews

Quarterly reviews at IdP, automated deprovisioning

Emergency access

Break-glass accounts per cloud (stored securely)

Never Use Long-Lived Credentials

Workload identity federation eliminates the need for long-lived API keys, access keys, or service account keys. If you are still using static credentials for cross-cloud access, migrate to federated identity immediately. Long-lived credentials are the number one cause of credential leakage incidents in cloud environments.

[Multi-Cloud IAM Comparison](https://cloudtoolstack.com/learn/multi-cloud-iam-comparison)[AWS Cognito Guide](https://cloudtoolstack.com/learn/aws-cognito-guide)