TL;DR
Federation sounds like an enterprise feature you buy and bolt on. It isn’t. If you have ever assumed an IAM role in AWS using an external identity, you have already done federation. The pattern is the same one that brokers identity across vendors: stop asking “do you hold the right secret?” and start asking “do you carry a valid assertion from an authority I trust?” Once you see AWS through that lens, moving to a cross-vendor identity fabric like Ping is a change of scope, not a change of model.
The reframe
Most engineers meet federation as a checkbox. Set up SAML SSO so people can log in with their corporate account. Done, filed under enterprise IT.
That framing hides how often you already do it. Every time a workload assumes an IAM role, that is federation. Every time a GitHub Actions job pushes to AWS without a stored key, that is federation. The mechanics you reach for on an ordinary Tuesday are the same mechanics that power a cross-company identity fabric.
A secret-based system asks one question: do you hold the right secret? Anyone holding it gets in, which is exactly why a leaked key is catastrophic. A federated system asks a different question: do you carry a valid, signed assertion from an authority I already trust? The resource never holds your credential. It holds a trust relationship with an authority, and it evaluates a short-lived token that authority issued.
That is the whole idea. Trust an authority, not a secret.
The mental model
Watch what actually happens when a workload assumes a role with web identity. There is no AWS secret on the workload. There is a token from an issuer AWS was configured to trust.
The workload never stored an AWS key. It presented proof from an authority. AWS checked three things: is this issuer one I trust, is the token genuinely from it, and do the claims satisfy the role’s conditions. Only then did it mint credentials, and those credentials expire in an hour by default, bounded by the role’s max session duration.
The translation table
The reason AWS feels different from “real” federation is naming. Line up the terms and the gap disappears.
| What AWS calls it | What it is in federation terms |
|---|---|
| IAM role trust policy | Establishing the trust relationship with an authority |
sts:AssumeRoleWithWebIdentity / AssumeRoleWithSAML | Exchanging an external assertion for local access (token exchange) |
| STS temporary credentials | A short-lived access token, scoped and time-boxed |
| OIDC / SAML identity provider in IAM | Registering the issuer you are willing to trust |
| IAM Identity Center | The human SSO front end on the same machinery |
None of these are AWS inventions. They are OIDC, SAML, and OAuth 2.0 assertion-exchange patterns with AWS labels on them. AssumeRoleWithWebIdentity maps most closely to a JWT bearer grant (RFC 7523): present a signed token, get a credential back. You learned the concepts already. You learned them under product names.
Where it gets interesting: machines
Run the model forward and the human story turns out to be the small one.
AssumeRoleWithWebIdentity is how a CI runner, a Kubernetes pod, or a Lambda gets into AWS with no long-lived key. The GitHub Actions to AWS OIDC integration is the cleanest example. The runner authenticates to GitHub’s OIDC issuer, receives a signed token describing the repo and branch, and trades it for short-lived AWS credentials. There is no AWS_SECRET_ACCESS_KEY sitting in a secret store waiting to leak.
That is workload identity federation, and it is the answer to the problem that quietly dominates every cloud account: there are far more non-human identities than human ones, and the old way to authenticate them was a static key that nobody rotates. A stale access key is a shared secret with no expiry and no owner. Federation replaces it with an assertion that expires in an hour by default — bounded by the role’s max session duration — and is scoped to the exact workload that asked.
If identity is the perimeter, the machine side of that perimeter is the larger one, and federation is the structural way to defend it at scale.
Misconceptions worth killing directly
“Federation is just SSO.” SSO is one application of federation, the human-login one. The pattern is broader: any time a resource trusts an authority instead of holding a secret, that is federation, humans or machines.
“Assuming a role is an AWS thing, not federation.” It is the textbook case. Trust policy, external assertion, token exchange, short-lived credential. That is federation with the serial numbers filed off.
“We use access keys, so we don’t do federation.” Then you are doing the secret model, and the access keys are the risk this whole pattern exists to remove. The fix is not a bigger vault. It is to stop holding the secret.
AWS in one ecosystem, Ping across many
If AWS already does federation, what does a dedicated identity platform add? Scope.
AWS plays both roles inside one boundary. It is the authority that issues the assertion and the relying party that consumes it. Clean and self-contained, as long as everything lives in AWS.
The real world is not one ecosystem. You have Okta for the workforce, Entra for Microsoft, a SaaS app expecting SAML, a partner who only speaks OIDC, and workloads spread across clouds. Now the authority and the relying party are different vendors who have never met. Something has to broker the trust, translate the protocols, and decide whose assertions count for what. That brokering across heterogeneous environments is what platforms like Ping do.
The model does not change. The protocols are the ones you already used in AWS. What changes is that no single vendor owns both ends anymore, so trust has to be deliberately established and managed rather than assumed because everything happened to be in the same account. That is the step up from “federation inside AWS” to “federation as architecture.”
Security note
The durable security win here is structural: replace long-lived credentials with short-lived, scoped assertions. A leaked access key is valid until someone notices and rotates it, which in practice means a long time. A federated credential is valid for an hour by default, bounded by the role’s max session duration, and is bound to conditions. That sharply limits the blast radius and exposure window a leaked token can be used in, compared to a key that stays valid until someone notices it.
That win only holds if the trust condition itself is scoped tightly. A GitHub OIDC trust policy whose sub condition covers an entire org (repo:acme-corp/*) instead of one repo and branch lets any workflow in that org assume the role. That’s a well-documented real-world misconfiguration, not a theoretical one. A loosely-scoped trust policy fails the same way a leaked secret does: anyone who satisfies one condition gets in.
When you adopt federation, audit for the credentials it was supposed to eliminate, and audit the trust policy’s own conditions with the same rigor. A workload that still carries a static key alongside a working OIDC trust is keeping the back door open next to the front one. Treat any remaining long-lived key, or an unscoped trust condition, as a finding, not a fallback.
