Loading...
System Design and AI Engineering, by Roni Das. 980 interactive lessons.
Start LearningIntermediate · Security Architecture
Two separate organisations or systems agree to trust each other's logins, so a person or a program proven at one is accepted at the other without a second account or a stored password.
In short
Identity federation means two separate systems agree to trust each other's logins. A person, or a program, proves who they are to their home system, and the other system accepts that proof. No second account is created, and no password or long-lived key (a secret that works for months or years) is stored on the other side. Three common examples: "Sign in with Google" on another company's website. Staff logging in to AWS, Amazon's cloud, with their company account. A GitHub Actions job (code that GitHub runs for you automatically) deploying to AWS with no stored key.
In short
Identity federation means two separate systems agree to trust each other's logins. A person, or a program, proves who they are to their home system, and the other system accepts that proof. No second account is created, and no password or long-lived key (a secret that works for months or years) is stored on the other side. Three common examples: "Sign in with Google" on another company's website. Staff logging in to AWS, Amazon's cloud, with their company account. A GitHub Actions job (code that GitHub runs for you automatically) deploying to AWS with no stored key.
Learn it in the course
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Identity Federation across a run of lessons, not one page. These 4 alone are about 72 minutes of step-by-step reading, every one with a quiz.
How identity federation lets people log in across organizations with one account. Compares SAML and OpenID Connect, and hub-and-spoke vs mesh.
Security Assertion Markup Language, the XML-based protocol that powers enterprise single sign-on and identity federation.
Storing, accessing, and rotating sensitive credentials. API keys, database passwords, tokens, and certificates.
An identity layer built on OAuth 2.0, the modern protocol for 'Sign in with Google/GitHub/Apple'.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Identity Federationpay once,
yours for life
Think of a passport. You get it from your own country. When you land in another country, they do not make you a new identity card. They check that the passport is real, because the two countries agreed to trust each other's passports. Federation is that agreement, for logins.
Every login system is an identity domain: a place that knows a set of people or programs and can prove who they are. Your company's login (an identity provider, or IdP) is one domain. AWS is another. A partner company's portal is a third.
Without federation, each domain needs its own account for you, with its own password. With federation, the systems set up trust once. The trusting system gets the identity provider's public key, the half of a key pair that anyone may see, so it can check that provider's signatures. Only the provider holds the private half, so only it can sign. After that, your home IdP signs a short message that says who you are, and the other system checks the signature and lets you in.
People search for "identity federation vs SSO" because the two are often used together. They answer different questions.
So a company's staff logging in to Salesforce with their company account is SSO for the staff, and it works because of federation between the company's IdP and Salesforce. The protocols are the same ones SSO uses: SAML for many business apps, and OpenID Connect (OIDC) for newer web apps and for programs.
AWS is where many engineers first meet the term, because AWS uses it in three places.
In every case, AWS hands back temporary security credentials: three codes (an access key ID, a secret access key and a session token) that together let a program in. The AWS API reference says they last one hour by default. You can ask for anything from 15 minutes up to the role's maximum, which an admin sets between 1 and 12 hours. When they expire, they are useless to anyone who stole them. That is the real security win of federation: there is no long-lived secret to leak.
This is the part of federation a working engineer meets most often. The old way to let a GitHub Actions job deploy to AWS was to create an AWS access key and paste it into GitHub as a secret. That key never expires, and anyone who reads it can use it from anywhere.
With federation there is no stored key. GitHub runs an OpenID Connect provider at https://token.actions.githubusercontent.com. When the job runs, it asks this provider for a signed token about itself. A repository is a project's code on GitHub, and a branch is one line of work in it. The token's subject (sub) names the repository, and the branch or environment, the job runs for. For example: repo:octo-org/octo-repo:environment:prod. The job sends the token to AWS STS (Security Token Service). STS checks the signature, then checks the IAM role's trust policy, which says which tokens may use the role. If both pass, STS returns credentials that expire soon. GitHub's docs put the benefit simply: "You won't need to duplicate your cloud credentials as long-lived GitHub secrets."
The trust policy is where the security lives. Here is one statement from an example trust policy. It goes inside the policy's Statement list. The role trusts GitHub's provider, but only for one repository's main branch.
One statement from an example IAM role trust policy (shape from the GitHub and AWS docs)
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:my-org/my-site:ref:refs/heads/main"
}
}
}
The sub condition is the line that matters. A policy that trusts the GitHub provider but does not pin the subject trusts every repository on GitHub that can get a token, including an attacker's. Google Cloud (workload identity pools) and Azure (federated credentials) work the same way, with their own names for the parts.
Federation is a core idea of zero trust: every request carries a fresh proof of identity that can be checked, instead of trusting anyone who is inside the company network. The identity federation lesson in the System Design course covers the protocols side by side, and how to connect many organisations: through one central hub, or each to each.
AWS
AssumeRoleWithWebIdentity and AssumeRoleWithSAML turn a trusted outside login into temporary AWS credentials, one hour by default.
GitHub Actions
Runs an OpenID Connect provider so a workflow job can prove which repository and branch it belongs to, with no stored cloud secret.
Google Cloud's workload identity federation lets outside workloads use short-lived credentials; Sign in with Google federates people into other sites.
Okta
A common home identity provider whose SAML or OIDC logins other companies' apps and clouds are set up to trust.
Identity federation means one system trusts another system's logins. You prove who you are to your home system, it signs a message saying so, and the other system checks the signature and lets you in. No second account or password is created on the other side.
Single sign-on is the experience of logging in once and opening many apps. Identity federation is the trust between two separate identity systems that lets a login from one be accepted by the other. SSO across company boundaries is built on federation, and federation can also be used by programs with no person involved.
It is how AWS lets outside identities in without AWS passwords or long-term keys. A user or program logs in to a trusted identity provider using SAML or OpenID Connect, then AWS STS exchanges that proof for temporary credentials for an IAM role. They last one hour by default, and up to 12 hours if the role allows it.
It is identity federation for programs instead of people. A CI job, a Kubernetes pod or a program in another cloud gets a signed token from its own platform and exchanges it for short-lived cloud credentials. GitHub Actions to AWS is the common example: no access key is stored in GitHub.
SAML 2.0 and OpenID Connect are the two common ones. SAML uses signed XML assertions and is common for business apps. OpenID Connect uses signed JSON Web Tokens and is common for web apps, mobile apps and workload federation.
Checked against these on .
Single Sign-On (SSO)
You log in once, at one trusted login service, and then open many separate apps without typing a password again. Each app trusts a signed message from the login service instead of keeping its own passwords.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
Secret Management
Securely storing and distributing credentials, API keys, and certificates. Tools like Vault, AWS Secrets Manager, and SOPS prevent secrets from leaking into code or logs.
Zero Trust
A security model that never trusts any request by default, even from inside the network. Every request must be authenticated, authorized, and encrypted regardless of origin.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
This page explains the idea. The "Identity Federation" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Identity Federation lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Identity Federation in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
