Identity federation across AWS, Azure, and GCP is one of those topics that sounds elegant in a slide deck and behaves like a cat once you actually open the door. On paper, it’s a graceful idea. One identity, many clouds, seamless access, unified control. In practice, it’s three hyperscalers politely agreeing on standards and then interpreting those standards like three different jazz musicians handed the same sheet music and told to improvise.
Federation always starts with optimism. Someone says, “We’ll centralize identity.” Everyone nods. The whiteboard fills with arrows. The word “single” appears in front of “sign-on” and nobody flinches. This is the moment when hope is strongest and logs are still quiet. Identity feels abstract, almost philosophical. You haven’t yet met the service account that was created during a proof of concept in 2019 and never forgiven.
The first realization comes gently. Azure thinks in tenants and conditional access policies. AWS thinks in accounts, roles, and trust policies that read like legal contracts drafted by someone who hates commas. GCP shows up smiling, talks about projects and workload identity, and quietly assumes you already understand what it meant. All three agree that federation is supported. None of them agree on how much responsibility belongs to you once you enable it.
SAML arrives wearing a tuxedo and carrying decades of experience. OIDC shows up in sneakers, promising simplicity and JSON. Both work, both are correct, and both will betray you the moment clocks drift, certificates expire, or someone copies an audience value from a blog written during a beta. Federation failures rarely announce themselves loudly. They prefer subtlety. A developer can’t deploy. A pipeline starts returning access denied. A production outage is blamed on networking for forty-five minutes before identity quietly clears its throat.
Trust is the real currency here, not tokens. Azure trusts an external role. AWS trusts a token issuer. GCP trusts a workload identity pool. Somewhere in the middle sits a claim transformation that decides whether you are an engineer, an admin, or just a confused human with a browser tab open too long. One missing claim and the whole arrangement collapses like a folding chair. The error message will say something inspirational like “Invalid audience” and provide no further guidance, as if this is a character-building exercise.
The funniest part is that federation is often introduced to reduce complexity. Instead of managing credentials in three clouds, you manage identity once. What actually happens is that credentials are replaced by diagrams. Beautiful diagrams. Diagrams with arrows that mean “trust” and footnotes that mean “this only works if everyone behaves.” The complexity doesn’t disappear. It just migrates into policy engines, token lifetimes, and conditional access rules that are technically correct and emotionally exhausting.
Then there’s the human factor. Someone needs break-glass access. Someone else hardcodes a role ARN because “it was faster.” A third person tests federation with an account that bypasses conditional access and declares success. Months later, during an incident, nobody remembers which cloud is the source of truth anymore. Identity becomes a mystery novel where every suspect has partial alibis and the detective is CloudTrail, Sign-In Logs, and Stackdriver arguing in different time zones.
Yet, despite all of this, federation is still worth it. When it works, it feels like good architecture. Access is short-lived. Secrets stop lingering. Auditors smile cautiously. Engineers log in once and move between clouds without summoning a password manager demon. The trick is accepting that federation is not a set-it-and-forget-it feature. It’s a living system. It needs monitoring, ownership, testing, and the occasional apology email.
Identity federation across AWS, Azure, and GCP is less like building a bridge and more like hosting a dinner party for three very capable guests who insist on cooking in your kitchen at the same time. It can be done. It can even be delightful. But only if you accept that identity is not plumbing. It’s diplomacy, with JSON.
And like all diplomacy, success depends less on the protocol and more on whether you remembered to rotate the keys, renew the certificates, and check who’s actually allowed in the room.