TL;DR: Aembit can now provide a security token service that brokers between first-party identity tokens and third-party access tokens across AWS, Azure, and GCP, as well as certain SaaS services like GitHub, GitLab, and Terraform. With the Aembit Workload IAM platform, each token issued is backed by identity-based policy enforcement, MFA checks for machines, and centralized auditing. This is all possible without building identity federation code into your applications.
Why Identity Federation is the Future of Access
The cloud-native world has been slowly – and painfully – admitting a truth we’ve all known for years:
Sure, they’re easy at first. An API key here. A service account token there. A shared credential passed into a CI/CD pipeline. Maybe you put them in a secrets manager, set up a cron job to rotate them every 90 days, and call it done.
But over time, secrets turn into landmines.
Every new workload, every environment, every integration (each of which is growing by leaps and bounds) adds another long-lived credential that someone has to manage, secure, rotate, and – eventually – remember to remove. The operational burden is real. The security risk is worse.
That’s why many teams are shifting to identity federation.
By using identity federation, you can delegate trust to your identity provider or token service, and issue short-lived, scoped access credentials based on workload identity credentials. No secrets to manage. No static credentials embedded in code. No rotation required.
But while the security story is sound, the reality of implementing and operating identity federation? That’s still a mess.
Security teams want to enforce strong identity-based access controls for workloads—things like enforcing attestation, validating runtime conditions, or requiring TPM-backed identity assertions before granting access. But that puts the burden on developers to build federation and these additional checks into their app logic. Each cloud speaks its own identity federation dialect, meaning you need a PhD in federation to get it right.
Which means that even if you know you should be using identity federation, you’re probably not.
Meet the Identity Federation Hub
The Aembit Identity Federation Hub is designed to turn identity federation from a bespoke, app-level concern into a unified platform capability.
You configure federation once – between Aembit and your identity provider or security token service – and then reuse it across all your workloads: containers, serverless functions, on-prem services, SaaS automations, AI agents, and more.
The federation logic is removed from your application. Static, long-lived credentials disappear – and so do all the management and rotation projects that go along with them. And policy enforcement becomes centralized and consistent.
With Aembit, you can also do some things that traditional federation leaves out entirely:
1) Evaluate and enforce access policies.
2) Enforce MFA for machines.
3) Centrally audit access across clouds.
You don’t just “enable federation” – you enforce real security.
Understanding Identity Federation (and Why It’s So Powerful)
At its core, identity federation is about delegating trust.
Instead of hardcoding credentials into a workload or automation tool, you allow it to prove who it is to an external identity provider – like AWS, Entra ID, Google Cloud – and receive a short-lived, first-party identity token in return. That token can then be traded for a short-lived access token to a third-party service or resource, like an API or cloud account.
Think of it like going to a concert. You don’t need to bring a stack of paperwork to prove you bought a ticket – you simply show your phone which verifies your identity via FaceID, then the ticket scanner verifies a ticket(token), and hands you a wristband.
To make that happen, the ticket scanner is trusting an issuer (Say, Ticketmaster) through a pre-arranged configuration. What results from that is a wristband, which is then your federated access token: it’s scoped, time-limited, and revocable.
In the world of non-human identity, the same pattern applies:
- A workload presents its identity (e.g., a signed JWT, metadata, or workload attestation).
- The identity provider verifies it and issues a token.
- That token is used to access a downstream system, which trusts the original identity provider, and exchanges the original identity token for an access token.
This model eliminates the need for long-lived secrets and makes access inherently safer. Credentials don’t sit around waiting to be leaked. They’re issued just-in-time, with a tight scope and short expiration.
But while the concept is elegant, the implementation is anything but.
Every provider has its own mechanism. AWS uses IAM roles and web identity federation. GCP has workload identity pools. Azure uses service principals. GitLab has its own OpenID Connect claims. Some systems use SAML. Some expect OIDC. Some expect magic headers.
Federation isn’t one thing – it’s 20 different things, all slightly incompatible.
And that’s just the setup. Once you’ve figured out how to federate a workload in, say, GitLab to AWS, you have to:
- Write the logic to fetch and exchange tokens.
- Handle role assumptions and session lifetimes.
- Secure the identity assertion mechanism.
- Figure out how to code MFA-like checks
- And log everything (good luck with that).
In other words, federation shifts you away from secrets, but into a lot of custom work. Work that repeats for every team, every service, every integration.
And that’s exactly the problem Aembit set out to solve with the Identity Federation Hub.
With and Without Aembit
Let’s look at what this means in practice.
Say you’re a developer, and your application is deployed in Azure.
You access services in Azure using service accounts and your operations team have been migrating storage to GCP due to availability and pricing. You decide to configure workload identity federation between Azure and GCP.
This requires configuration on both Azure and GCP. Furthermore, you know you’re going to be using AWS Bedrock and you’d like to configure WIF for that access as well. Now you’re wondering how you’re going to set up the access for Azure to GCP, Azure to AWS, and AWS to GCP as well as AWS to Azure.
This is beginning to get confusing, and you haven’t even taken into account the dozen other services your application uses or the amount of code needed to fetch all of these credentials and use them
Wouldn’t you like to make this whole thing easier? Enter Aembit.
Configure workload identity federation for each one of your cloud service providers. Aembit now has a relationship with each of the cloud service providers (CSPs) and can get short-lived tokens when needed.
Next, add each service that you’d like to connect to. In this example, it’s Google BigQuery. You’ll repeat this for each service you’d like to access.
Lastly, you create access policies that allow your application to access all of the services needed using short-lived, federated tokens. Here are the policies that allow our backend microservices to access our three services, Google BigQuery, AWS Bedrock, and Azure Event Grid, using the various flavors of WIF.
Expanding this deployment has now been extremely simplified. If you’d like to give another application or server access, you simply create a new client workload and clone the access policies.
If you’d like to allow access to other services in the CSP or on-premises or in a SaaS, you simply add a new server workload and clone the access policies.
Federation Has Gaps Too: Policy, MFA, and Auditing
Even when teams succeed in wiring up federation manually, they almost always fall short on the goal of secure, managed access.
First, when federation is used it’s most likely being wired up as 1:1 connections between services, with no centralized management. That means that security or DevSecOps has no ability to enforce access policies, without requiring an burdensome process to report access and then file tickets when something needs to change. (Kudos to your team if you’re one of the few who’ve built a custom access proxy to manage some of this!)
And almost no team is enforcing MFA for machines. There’s no easy way to say: “This verified workload should only be allowed access if it’s running within the United States, during a specific time window, actively managed by Wiz and only if it was deployed via an approved pipeline.”
Developers aren’t adding these checks to their apps, and it’s too much to ask that they do this for every piece of code they build. And identity providers – or your cloud providers – aren’t giving you the policy hooks to enforce it.
Aembit does.
With Aembit, every access decision is policy-driven. You can write conditional access policies that enforce the workload equivalent of MFA – and they’re applied automatically before any federated credential is issued.
And because Aembit handles the full lifecycle of the token exchange, every detail is logged in order to accelerate auditing and compliance:
- Which identity was verified.
- Which policy was enforced.
- Which conditions were present.
- Which credential was issued.
- Which resource was accessed.
It’s the kind of clarity security teams crave – and the kind of automation developers shouldn’t have to build themselves.
Why It Matters Now
We’re in a world where environments are increasingly hybrid. SaaS tools drive automation. DevOps pipelines operate across clouds. Autonomous AI agents are coming. And workloads have more access to sensitive resources than ever.
Identity is the right foundation for securing access. But federation isn’t something you should build and maintain for every workload.
With the Identity Federation Hub, we take that burden off your plate. You set up trust once. Reuse it everywhere. And govern it from a single control plane.
No secrets. No duplication. No drift. Just secure, federated access – built for the way modern infrastructure actually works.
See It In Action
We’re excited to share this capability with you. If you’re looking to ditch secrets, standardize access, or finally get a handle on federation and workload identity, we’d love to show you how Aembit can help.
These federation capabilities are available today as part of our core product. And we’re continually federating with more SaaS providers to make this as simple and complete as possible for you.
We’ve done the hard work so you don’t have to.
Let’s move beyond secrets and make identity federation what it was always meant to be: simple, scalable, and secure.
👉 Federating workloads with Google Workload Identity
👉 MFA for Machines
👉 Try the Identity Federation Hub
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
