IAM Identity Center vs SAML Federation vs Cognito Identity Pools: Picking the Right One
AWS gives you three separate ways to let someone outside IAM obtain temporary AWS credentials, and the exam (and real architecture reviews) loves to blur them together: IAM Identity Center, SAML 2.0 or OIDC federation directly into IAM, and Amazon Cognito identity pools. All three end with a caller holding short-term credentials from AWS STS. The difference is who the caller is and what they're trying to reach, and AWS's own IAM documentation draws the line sharply enough that most of the confusion is avoidable once you see the three side by side.
The one-sentence version of each
- IAM Identity Center (the 2022 rename of AWS SSO) is for your workforce — employees who need single sign-on into multiple AWS accounts and business applications, managed centrally across an AWS Organizations structure.
- SAML or OIDC federation directly into IAM is for a single, standalone AWS account that isn't using Identity Center — typically a small deployment, a short-term human-user scenario, or a machine workload (like a CI pipeline) authenticating with OIDC.
- Cognito identity pools are for the end users of an app you built — customers signing into your mobile or web app who need their own scoped AWS credentials, not console access.
The three are not tiers of the same thing; they solve for different populations. Identity Center and direct IAM federation both grant administrative or operational access to AWS itself. Cognito identity pools grant application access on behalf of a customer who has never heard of your AWS account.
Side-by-side comparison
| IAM Identity Center | Direct federation into IAM | Cognito identity pools | |
|---|---|---|---|
| Who it's for | Your organization's human workforce | Human users (short-term, single account) or machine workloads | Your app's external end users (customers) |
| Account scope | Multiple AWS accounts under AWS Organizations | A single, standalone AWS account | Any account; not tied to Organizations |
| Identity source | Built-in Identity Center directory, Active Directory, or an external SAML IdP | A SAML 2.0 or OIDC identity provider registered directly in IAM | Cognito user pools, SAML, OIDC, or social IdPs (Google, Facebook, Apple, Amazon) |
| What the user reaches | The AWS access portal: console access across accounts, plus SAML-integrated business apps | AWS API calls or console access in that one account | Direct, scoped AWS API access from inside your application |
| Underlying STS mechanism | Brokered: signing in through the access portal silently maps the user to a permission set, which is an IAM role in the target account — you never call AssumeRole yourself | sts:AssumeRoleWithSAML (SAML) or sts:AssumeRoleWithWebIdentity (OIDC), called explicitly by the client app with the IdP's assertion or token | sts:AssumeRoleWithWebIdentity, called by Cognito on the app's behalf after it validates the user's token |
| Authenticated vs. guest access | Not applicable — every session is tied to a signed-in workforce identity | Not applicable — every session requires a valid assertion | Supports both: an authenticated role for signed-in users and a separate unauthenticated (guest) role for anonymous visitors |
That STS row is the detail people get backwards most often: Cognito identity pools and OIDC-based direct-IAM federation both end up at the same API, AssumeRoleWithWebIdentity — the difference is that Cognito calls it for you after validating the user's token, while direct OIDC federation into IAM means your own application code makes that STS call. SAML federation into IAM uses a different, dedicated API, AssumeRoleWithSAML, because a SAML assertion isn't a JSON web token and needs its own validation path.
Three scenarios, worked through
Scenario 1 — a growing company with 14 AWS accounts. Engineers currently get a separate IAM user in every account they touch, and offboarding someone means hunting across all 14. The fix is IAM Identity Center: connect it to the company's existing Active Directory (or an external IdP) as the identity source, create permission sets that map to job functions (ReadOnly, PowerUser, NetworkAdmin), and assign users and groups to accounts through the access portal. One sign-in, short-term credentials, and offboarding is a single directory change instead of 14 IAM user deletions.
Scenario 2 — a single-account startup that doesn't want to stand up Identity Center. A small team wants engineers to authenticate against the company's existing Okta tenant for console access, without provisioning IAM Identity Center at all. This is the textbook case for direct SAML federation into IAM: register Okta as a SAML provider entity in that one account, create a role with the SAML provider as the trusted principal, and have engineers' client call AssumeRoleWithSAML (or sign in through Okta's AWS tile, which does this under the hood). No Organizations, no permission sets — just one account trusting one IdP.
Scenario 3 — a mobile app letting signed-in users upload photos straight to S3. The app already uses a Cognito user pool for sign-up and sign-in. To let a signed-in user's phone upload directly to an S3 bucket — without routing the file through a backend server, and without embedding any long-lived AWS key in the app — the app creates a Cognito identity pool, configures the user pool as a federated identity provider, and maps authenticated users to an IAM role scoped to s3:PutObject on a per-user prefix. The identity pool exchanges the user pool's token for temporary credentials via AssumeRoleWithWebIdentity, and the phone never sees a password or an access key for the bucket itself. A separate, far more restricted role can be assigned to unauthenticated guests if the app allows browsing without signing in.
Two mistakes that show up constantly
The first is confusing Cognito user pools with Cognito identity pools. A user pool is a user directory: it handles sign-up, sign-in, password resets, and issues JSON web tokens. An identity pool is a credential broker: it takes a token (from a user pool, a SAML IdP, an OIDC IdP, or a social provider) and exchanges it for temporary AWS credentials. Many real apps use both together — a user pool for authentication, an identity pool for authorization to AWS resources — but they are two different services solving two different problems, and a question that only mentions "sign-up and sign-in" is pointing at a user pool, not an identity pool.
The second is assuming direct SAML or OIDC federation into IAM is simply "Identity Center without the extra setup." AWS's own guidance is the opposite: it recommends Identity Center for workforce access and treats direct IAM federation as the fallback for a single account that specifically isn't using Identity Center, or for machine identities (like a GitHub Actions OIDC provider) that don't belong to a human workforce at all. If a scenario mentions multiple AWS accounts and centralized workforce access, Identity Center is almost always the intended answer, even if a SAML IdP is also mentioned — Identity Center can use an external SAML IdP as its identity source, which is a different thing from federating that IdP straight into one account's IAM.
Quick decision checklist
| If the scenario says… | Reach for… |
|---|---|
| "Employees," "multiple AWS accounts," "centralized access," "AWS Organizations" | IAM Identity Center |
| "Single account," "don't want to enable Identity Center," "CI/CD pipeline," "GitHub Actions" | Direct SAML (AssumeRoleWithSAML) or OIDC (AssumeRoleWithWebIdentity) federation into IAM |
| "Mobile app," "web app," "end users," "sign in with Google/Facebook/Apple," "no backend credential handling" | Cognito identity pools |
For more on how IAM evaluates roles, policies, and trust relationships once any of these three mechanisms hands back temporary credentials, see the AWS SAA IAM & security practice questions, which cover identity-based versus resource-based policies, cross-account role assumption, and KMS key policies as separately tested scenarios.
This is educational exam-prep material, not a deployment guide — validate any production federation setup against the current AWS documentation before building on it.
Source: AWS Identity and Access Management User Guide, "Identity providers and federation into AWS" and "SAML 2.0 federation" (docs.aws.amazon.com/IAM/latest/UserGuide/); AWS IAM Identity Center User Guide, "What is IAM Identity Center?" (docs.aws.amazon.com/singlesignon/latest/userguide/); Amazon Cognito Developer Guide, "Identity pools console overview" (docs.aws.amazon.com/cognito/latest/developerguide/); all retrieved 2026-10-08.