Identity Federation Bundle

SAML 2.0, OpenID Connect (OIDC), Amazon Cognito, and AWS IAM Identity Center (formerly AWS SSO) — four pieces of the same underlying puzzle: letting an identity that doesn't natively live in AWS IAM get temporary, scoped AWS access. The exam tests whether you know WHO the identity belongs to (workforce vs customer vs machine/CI-CD) and which federation protocol/service fits that population.

Identity — primary role Preventive — scoped temporary credentials, not long-lived keys Governance — centralized workforce access

XML

SAML assertion format

JWT

OIDC token format

20

Max passkeys per Cognito account

TTI

Trusted Token Issuer — any OIDC issuer, broadened 2026

The Core Mental Model — Match the Population to the Service

Four Tools, Four Different Populations

SAML 2.0 — the legacy-enterprise federation protocol. An XML-based assertion issued by an external Identity Provider (IdP) — Okta, Azure AD, ADFS, PingFederate — is exchanged via AssumeRoleWithSAML for temporary AWS credentials. Browser-based, IdP-initiated or SP-initiated sign-in flows.
OpenID Connect (OIDC) — the modern, token-based federation protocol built on OAuth 2.0. Identity is expressed as a signed JSON Web Token (JWT), exchanged via AssumeRoleWithWebIdentity. This is the mechanism behind "Login with Google/Facebook," and also the standard way CI/CD systems (GitHub Actions, GitLab CI) get short-lived AWS credentials without storing long-lived secrets.
Amazon Cognito — purpose-built for CUSTOMER-FACING applications at scale (millions of users). User Pools handle authentication (who is this person — sign-up, sign-in, MFA, passwordless/passkeys). Identity Pools handle authorization (what can they do in AWS — issuing temporary, scoped AWS credentials via STS).
AWS IAM Identity Center — purpose-built for WORKFORCE access across an entire AWS Organization. Centralizes SSO for employees into many AWS accounts and SAML/OIDC-enabled business applications, using Permission Sets instead of you manually managing IAM roles per account.

⚠️ The Recurring Exam Theme

Identity Federation questions almost always test whether you can identify WHO the identity belongs to. Workforce/employee accessing many AWS accounts → IAM Identity Center. App's own customers (potentially millions) → Cognito. An enterprise's existing corporate directory federating in via assertions → SAML. A CI/CD pipeline or mobile/web app needing token-based, no-stored-secret access → OIDC. Mixing these up is the single most common trap in this domain.

Exam Domain Mapping

Domain	Where This Bundle Shows Up
Identity & Access Management	The centerpiece — federation protocol selection, temporary credential issuance, permission scoping
Management & Security Governance	IAM Identity Center org-wide deployment, permission sets, ABAC
Infrastructure Security	Verified Access integration with Identity Center/SAML IdPs for zero-trust application access
Data Protection	Trusted Identity Propagation preserving human identity context into Lake Formation/Redshift/S3 Access Grants

Decision Tree — Mental Model

Threat

Long-lived IAM user access keys distributed to employees/applications/CI-CD systems, creating standing credential risk; no centralized way to manage workforce access across many accounts; customer-facing apps needing their own identity store

↓

Security Goal

Issue short-lived, scoped AWS credentials to the right population through the right protocol, eliminating standing secrets wherever possible

↓

AWS Service

The Identity Federation Bundle

SAML — enterprise IdP assertions OIDC — tokens, CI/CD, mobile/web Cognito — customer-facing apps IAM Identity Center — workforce SSO

↓

Implementation

Configure the IdP/OIDC provider trust relationship; for workforce, deploy Identity Center org-wide with permission sets; for customers, deploy Cognito User/Identity Pools; for CI/CD, configure OIDC trust with the specific provider (no stored AWS keys).

↓

Monitoring

CloudTrail records every AssumeRoleWithSAML/AssumeRoleWithWebIdentity call; Cognito exports authentication event logs (Plus tier); Identity Center logs every SSO sign-in and permission set assignment.

↓

Remediation

Revoke/rotate the trust relationship, remove a compromised permission set assignment, or disable a Trusted Token Issuer if its signing keys are suspected compromised.

Final Summary

Must Memorize

SAML = XML assertions, enterprise IdPs, AssumeRoleWithSAML
OIDC = JWT tokens, AssumeRoleWithWebIdentity, the standard for CI/CD and mobile/web
Cognito User Pools = authentication; Identity Pools = authorization (temporary AWS credentials)
IAM Identity Center = workforce SSO across many AWS accounts via Permission Sets, not Cognito
Trusted Token Issuer (TTI) now accepts ANY OIDC-compliant issuer, not just AWS-hardcoded providers (broadened early 2026)

Must Understand

Why temporary, federated credentials are preferred over long-lived IAM user access keys
Trusted Identity Propagation's role in preserving human identity context into AWS analytics services
The distinction triangle: IAM Identity Center (workforce) vs Cognito (customers) vs raw SAML/OIDC federation (custom/CI-CD)

Can De-prioritize

Exact SAML XML schema syntax
Console UI navigation specifics
Full list of every Trusted Identity Propagation-compatible service

Exam appearance probability: HIGH

Core Services — Deep Dive

SAML 2.0 Federation XML assertions, enterprise IdPs

FormatXML-based signed assertion describing the authenticated user and their attributes

AWS APIsts:AssumeRoleWithSAML — exchanges the SAML assertion for temporary STS credentials

Trust setupCreate a SAML identity provider in IAM, establishing trust with the external IdP's metadata (signing certificate, entity ID)

FlowsIdP-initiated (user starts at the IdP's portal) or SP-initiated (user starts at AWS, gets redirected to the IdP)

The SAML assertion can include a custom attribute (commonly named https://aws.amazon.com/SAML/Attributes/Role) listing which IAM role(s) the user is permitted to assume — this is how SAML federation maps an external user to a specific AWS IAM role.
Classic use case: a large enterprise with an existing ADFS or Okta deployment wants employees to access the AWS Console without AWS managing separate IAM user credentials for each person.
"Federate using our existing on-prem Active Directory via ADFS, with browser-based sign-in" → SAML, the long-established standard for this kind of enterprise IdP integration.

OpenID Connect (OIDC) JWT tokens, built on OAuth 2.0

FormatSigned JSON Web Token (JWT) containing identity claims (issuer, subject, audience, expiration)

AWS APIsts:AssumeRoleWithWebIdentity — exchanges the OIDC token for temporary STS credentials

Trust setupCreate an OIDC identity provider in IAM, registering the issuer URL and audience (client ID) — AWS fetches the issuer's public signing keys automatically via its discovery document

The dominant CI/CD pattern: GitHub Actions, GitLab CI, and similar systems can request a short-lived OIDC token scoped to that specific pipeline run, exchange it for temporary AWS credentials via a configured IAM OIDC provider — completely eliminating the need to store long-lived AWS access keys as CI/CD secrets.
Also the mechanism behind consumer "Login with Google/Apple/Facebook" flows, and behind EKS's IAM Roles for Service Accounts (IRSA), which uses the cluster's own OIDC issuer to let individual Kubernetes pods assume scoped IAM roles.
"Let our GitHub Actions pipeline deploy to AWS without storing any AWS access keys as a repository secret" → OIDC federation, precisely because it avoids any standing credential entirely.

Amazon Cognito User Pools Authentication for customer-facing apps

What it answers"Who is this person" — sign-up, sign-in, MFA, password policies, social/SAML/OIDC IdP login

TiersLite (basic), Essentials (default for new pools — adds Managed Login + passwordless), Plus (adds risk-based adaptive auth, compromised-credential detection, threat protection)

Managed LoginThe modern replacement for the older "Hosted UI" — a responsive, customizable sign-up/sign-in web interface supporting passwordless flows

Passwordless / PasskeysWebAuthn passkeys (up to 20 per account), email codes, or SMS — passkeys with user verification can even satisfy MFA requirements

Scales to millions of users — this is the key differentiator from IAM Identity Center, which is sized and designed for an organization's workforce, not a consumer customer base.

Amazon Cognito Identity Pools Authorization — temporary AWS credentials

What it answers"What can this authenticated (or even unauthenticated/guest) user do in AWS" — issues temporary, scoped AWS credentials via STS

Identity sourcesCan federate from a Cognito User Pool, a third-party SAML/OIDC IdP, or allow fully unauthenticated guest access with its own restricted role

This is the classic exam trap: User Pools and Identity Pools solve DIFFERENT problems and are frequently used TOGETHER (authenticate via User Pool, then federate into an Identity Pool for AWS resource access) — they are not interchangeable or redundant.
"A mobile app needs to let unauthenticated guest users directly upload a file to S3 with very limited permissions" → Cognito Identity Pools' unauthenticated role.

AWS IAM Identity Center Workforce SSO across AWS Organizations

Formerly known asAWS SSO

Instance typesOrganization instance (recommended — manages access across every account in the Organization) or Account instance (single-account, app-specific)

Identity source categoriesIdentity Center's own built-in directory (default, AWS-managed), Active Directory (either AD Connector or AWS Managed Microsoft AD — see below), or an external IdP (Okta, Azure AD, Google Workspace, any SAML 2.0 provider) with optional SCIM auto-provisioning

Permission setsReusable collections of permissions (based on AWS managed policies or custom policies) assigned to a user/group for a specific AWS account — Identity Center provisions the underlying IAM role behind the scenes

ABAC supportAttributes from the identity source can drive attribute-based access control decisions across accounts

One source at a timeOnly ONE directory (or one SAML 2.0 IdP) can be connected to IAM Identity Center at any given time — not multiple simultaneously

Requires root or management-account access to enable initially, since it operates at the Organizations level.
Also provides SSO into other SAML-enabled business applications (not just AWS accounts) and supports secure access to EC2 Windows instances using existing corporate credentials, without sharing administrator credentials or configuring separate remote-access client software.
"Give 500 employees SSO access to the right permission level in each of our 30 AWS accounts, centrally managed" → IAM Identity Center with Permission Sets, not 30 sets of manually managed IAM users/roles.
Best practice timing: choose your identity source BEFORE creating any users/groups in the default Identity Center directory — switching identity sources later requires additional migration work that's avoidable by deciding upfront.

Connecting an EXISTING Active Directory — AD Connector vs AWS Managed Microsoft AD High — frequently tested, frequently confused

AD ConnectorA directory GATEWAY/PROXY — redirects authentication requests to your existing on-premises (or self-managed, EC2-hosted) Active Directory, WITHOUT caching any directory data in the cloud. Nothing is migrated or duplicated; AWS simply forwards the auth request to your real AD

AD Connector's key limitationStrictly a ONE-TO-ONE trust with a SINGLE AD domain — it does NOT support transitive trusts. IAM Identity Center can only access users/groups in that one specific domain attached to the AD Connector

AWS Managed Microsoft ADAn actual new, AWS-hosted Microsoft AD domain (via AWS Directory Service). Connects to your existing on-prem/self-managed AD via a TWO-WAY TRUST relationship (forest trust) rather than acting as a pure proxy

When AWS explicitly recommends Managed AD over AD Connector"If you need to support multiple domains or forests, use AWS Managed Microsoft AD" — this is AWS's own direct guidance, since trust relationships support multi-domain access in a way AD Connector's single-domain proxy model cannot

Location requirementThe AD Connector or AWS Managed Microsoft AD directory MUST reside in the AWS Organizations MANAGEMENT account — or, if using IAM Identity Center's delegated administrator feature, in that delegated administrator account instead

Region requirement (Managed AD specifically)If using AWS Managed Microsoft AD, IAM Identity Center must be enabled in the SAME REGION as that AWS Managed Microsoft AD directory — assignment data is stored in that Region

Configurable AD syncLets you explicitly scope WHICH users/groups sync from Active Directory into IAM Identity Center via Sync Filters (User or Group filters) — rather than syncing the entire directory by default, giving you a defined data boundary

Not supportedSAMBA4-based Simple AD cannot be used as an IAM Identity Center identity source at all. Foreign Security Principals (FSPs) — members of a Managed AD group who come from a trusted domain — do NOT sync, even if the group itself does

The exam framing: "We have a single, existing on-premises Active Directory domain. We want IAM Identity Center to authenticate against it directly, without duplicating or migrating any directory data into AWS" → AD Connector, precisely because it's a pure proxy with zero cloud-side data caching.
The contrasting framing: "We operate multiple AD domains/forests and need IAM Identity Center to see users across all of them" → AWS Managed Microsoft AD with a trust relationship, since AD Connector's one-domain, non-transitive-trust model cannot satisfy a multi-domain requirement.
Both options ultimately let users sign in to IAM Identity Center with their EXISTING corporate AD credentials — the difference is entirely in the underlying connection mechanism (proxy vs trust relationship) and how many domains each can reach.

Trusted Identity Propagation (TIP) Preserves human identity into AWS analytics services

What it doesBuilt on OAuth 2.0 — lets an application pass a signed-in user's identity context through to AWS services when creating an "identity-enhanced" IAM role session, instead of relying solely on the application's own IAM role permissions

Why it mattersAuthorization can now be evaluated against the actual HUMAN, not just the calling application — enabling per-user Lake Formation row/column rules, Amazon Q Business document ACLs, OpenSearch fine-grained access, and per-analyst Athena workgroup quotas

Supported targetsRedshift, Athena, Lake Formation/Glue, S3 Access Grants, SageMaker Studio, Amazon Q Business, Amazon Q Developer, OpenSearch Service, AWS Transfer Family, EMR Studio

Use TIP when authorization must run against the human identity itself. Stay with a plain service IAM role when only the application's own identity matters and the human isn't a meaningful security boundary (e.g. scheduled batch ETL jobs).

Trusted Token Issuer (TTI) High — exam-fresh, broadened early 2026

What it doesLets Identity Center exchange a token from ANY OIDC-compliant external issuer for a short-lived AWS session scoped to a specific permission set

StatusMoved out of preview during 2025; ecosystem support broadened significantly through early 2026

Supported issuersOkta, Auth0, an internal Keycloak, self-managed GitLab, even a Sigstore Fulcio instance or a SPIFFE/SPIRE federation — effectively any OIDC-compliant token source, not a fixed AWS-hardcoded list

Before TTI, federating a non-AWS-native identity source into Identity Center meant standing up a full SAML application, or routing users through an AWS-managed user pool — TTI removes that requirement for OIDC-compliant sources.
"We need to federate a custom internal Keycloak-issued OIDC token into Identity Center for short-lived, permission-set-scoped AWS sessions, without building a SAML app" → Trusted Token Issuer.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Federate an enterprise's existing Active Directory (via ADFS) for browser-based AWS Console access

ADFSenterprise IdPXML assertion

Expected Answer

SAML 2.0 federation (AssumeRoleWithSAML)

Distractor	Why it's wrong
Amazon Cognito	Built for customer-facing app authentication at scale, not enterprise workforce federation from an existing corporate IdP
OIDC	ADFS classically issues SAML assertions, not OIDC tokens, in this scenario — though modern ADFS can support OIDC too, SAML is the textbook-expected answer here

Configure IAM Identity Center to authenticate against a SINGLE existing on-premises Active Directory domain, without migrating or duplicating any directory data into AWS

existing ADno data migrationsingle domain

Expected Answer

AD Connector as the IAM Identity Center identity source

Distractor	Why it's wrong
AWS Managed Microsoft AD	Stands up an entirely new, separate AWS-hosted AD domain and requires configuring a trust relationship — far more than this single-domain, no-duplication requirement calls for
External SAML 2.0 IdP	Requires standing up a separate federation layer (e.g. ADFS) in front of the AD — AD Connector talks to the existing AD directly, no extra IdP component needed

Give IAM Identity Center visibility into users across MULTIPLE existing Active Directory domains/forests

multiple domainsmultiple forestscross-domain trust

Expected Answer

AWS Managed Microsoft AD, with a trust relationship to the existing domains

Distractor	Why it's wrong
AD Connector	Strictly a one-to-one trust with a SINGLE domain — does not support transitive trusts, so it structurally cannot reach multiple domains/forests at once

Let a CI/CD pipeline deploy to AWS without storing any long-lived AWS credentials as a secret

CI/CDno stored secretsGitHub Actions

Expected Answer

OIDC federation (AssumeRoleWithWebIdentity)

Distractor	Why it's wrong
Long-lived IAM user access keys stored as a repo secret	The exact anti-pattern OIDC federation is meant to eliminate — standing credentials with blast-radius risk
SAML	Designed for browser-based human sign-in flows, not the token-exchange pattern CI/CD systems use

Authenticate millions of customer-facing app users with passwordless/passkey sign-in

customer-facingmillions of userspasswordless

Expected Answer

Amazon Cognito User Pools

Distractor	Why it's wrong
IAM Identity Center	Sized and designed for workforce/employee SSO into AWS accounts, not millions of external app customers

Give 800 employees SSO into the correct permission level across 40 AWS accounts, centrally managed

workforce SSOmultiple AWS accountscentrally managed

Expected Answer

AWS IAM Identity Center with Permission Sets

Distractor	Why it's wrong
Manually configure SAML federation directly into each of the 40 accounts	Works but is exactly the unscalable, decentralized pattern Identity Center is built to replace
Cognito	Wrong population — built for customers, not workforce/employees

Let a custom BI application query Redshift on behalf of a signed-in user, preserving their identity for Lake Formation row-level rules

preserve user identityrow-level access controlon behalf of

Expected Answer

Trusted Identity Propagation

Distractor	Why it's wrong
A single shared service IAM role for the application	Loses the individual human's identity context entirely — Lake Formation can't apply per-user row/column rules against an undifferentiated application identity

Federate a custom internal Keycloak OIDC issuer into Identity Center without building a full SAML application

custom OIDC issuerno SAML app needed

Expected Answer

Trusted Token Issuer (TTI)

Distractor	Why it's wrong
Standing up a SAML application for Keycloak	The exact extra complexity TTI was introduced to remove for OIDC-compliant sources
Assuming TTI only works with AWS-hardcoded providers	Outdated — TTI broadened to support any OIDC-compliant issuer in early 2026

Integrations

AWS STS

WhatThe underlying service issuing temporary credentials for both AssumeRoleWithSAML and AssumeRoleWithWebIdentity

AWS Organizations

WhatIAM Identity Center's Organization instance operates at this level, requiring management-account access to enable

AWS Verified Access

WhatIntegrates with both IAM Identity Center (for SAML IdP-backed sign-in) and direct OIDC trust providers, centralizing authentication for corporate applications under one zero-trust model

Amazon Redshift / Athena / Lake Formation / S3 Access Grants / SageMaker Studio / Q Business / Q Developer / OpenSearch / Transfer Family

WhatCurrent Trusted Identity Propagation targets — services that can receive and act on the propagated human identity context

Amazon EKS (IRSA)

WhatUses the cluster's own OIDC issuer so individual Kubernetes service accounts/pods can assume scoped IAM roles via the same OIDC federation mechanism

SCIM Provisioning

WhatAutomatic, ongoing synchronization of users/groups from an external IdP into IAM Identity Center's directory

Costs, Limits & Quotas

Pricing Model

SAML / OIDC federation (raw IAM)No direct charge — you only pay for the resources accessed via the temporary credentials

IAM Identity CenterNo charge for the service itself; cost lives in your chosen identity source (e.g. AWS Managed Microsoft AD) and any AWS-managed application using Trusted Identity Propagation

CognitoTiered by monthly active users (MAUs) — Lite and Essentials both include a free tier (10,000 MAUs) that does not expire after 12 months; Plus is priced higher for its added threat-protection features

Common Cost Mistakes

Using Cognito's Plus tier (or the older Advanced Security Features) account-wide when only a subset of flows actually need risk-based adaptive authentication
Standing up AWS Managed Microsoft AD as an Identity Center identity source when a lighter option (the built-in directory, or AD Connector to existing on-prem AD) would suffice
Building custom SAML applications for OIDC-compliant sources that could instead use Trusted Token Issuer with far less integration overhead

Cost Optimization

Use Cognito's free tier (Lite/Essentials, 10,000 MAUs) for early-stage or lower-traffic applications
Use AD Connector instead of a full Managed Microsoft AD deployment when you only need to proxy to existing on-prem AD, not host a new directory
Prefer Trusted Token Issuer over building bespoke SAML applications for any OIDC-compliant identity source

Limits & Quotas

Cognito passkeysUp to 20 per account

Cognito free tier10,000 MAUs (reduced from the earlier 50,000 MAU tier), available indefinitely for both new and existing customers

Cognito MFA constraintCannot set MFA to required in user pools that also support one-time-password sign-in; passkeys with user verification are the one exception that can satisfy MFA on their own

IAM Identity Center setupRequires root or management-account access to enable initially

⚠️ Exam trap

Don't assume Cognito's free tier still matches older documentation/screenshots showing 50,000 MAUs — it was reduced to 10,000 MAUs as part of the November 2024 Lite/Essentials/Plus tier restructuring.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know

SAML = XML, enterprise IdPs; OIDC = JWT, CI/CD & modern apps
Cognito User Pools (authn) vs Identity Pools (authz/temp credentials) are distinct and complementary
IAM Identity Center = workforce; Cognito = customers — never conflate the two populations
TTI now accepts any OIDC-compliant issuer, not a fixed AWS list

Good Practice

Prefer OIDC federation over long-lived access keys for any CI/CD or machine-to-AWS pattern
Use Permission Sets in Identity Center instead of manually managing IAM roles per account
Enable passkey/passwordless options in Cognito to reduce phishing/credential-theft risk
Use Trusted Identity Propagation when human-level authorization granularity actually matters for the target service

Advanced Practice

Use ABAC in Identity Center to scale permission management via identity-source attributes rather than an ever-growing list of permission sets
Use Trusted Token Issuer to federate niche/internal OIDC issuers (Keycloak, SPIFFE/SPIRE) without building bespoke SAML apps
Combine Verified Access with Identity Center/SAML IdPs for a unified zero-trust application access architecture spanning both AWS and corporate apps

9 — Common Exam Traps

Misconception	Reality
"Cognito Identity Pools and User Pools do the same thing"	User Pools authenticate (who); Identity Pools authorize (what AWS access) — they solve different problems and are commonly used together
"IAM Identity Center is just Cognito for employees"	They're architecturally distinct services — Identity Center is built around Permission Sets and Organizations-wide account access, not user pool/identity pool concepts
"SAML and OIDC are interchangeable, pick whichever"	SAML = XML assertions for enterprise IdP browser flows; OIDC = JWT tokens for modern apps/CI-CD — the exam expects you to match the right protocol to the scenario's population and use case
"Trusted Token Issuer only works with AWS's officially listed identity providers"	Outdated — TTI broadened to accept any OIDC-compliant issuer during the 2025–2026 rollout, including internal/custom ones
"Storing AWS access keys as a CI/CD secret is an acceptable standard practice"	OIDC federation (AssumeRoleWithWebIdentity) is the AWS-recommended pattern specifically to avoid this standing-credential risk

Lookalike Comparisons

Comparison	What actually differs
SAML vs OIDC	XML assertions / browser-based enterprise SSO vs JWT tokens / modern web, mobile, and CI-CD token exchange
Cognito User Pools vs Identity Pools	Authentication (who is this person) vs authorization (temporary AWS credentials for what they can do)
Cognito vs IAM Identity Center	Customer-facing app users at scale (millions) vs internal workforce SSO across an AWS Organization's accounts
Trusted Identity Propagation vs a plain service IAM role	Authorization evaluated against the actual human identity (needed for per-user data access rules) vs authorization evaluated only against the calling application's identity (fine when the human isn't a security boundary)
Trusted Token Issuer vs building a SAML application	Lightweight OIDC token exchange for any compliant issuer vs the heavier, older pattern of standing up a full SAML app or AWS-managed user pool just to federate one external identity source

Flashcards — 19 Cards

Click card to flip. Mark right or wrong to track score.

Click to reveal answer

1 / 19

Mark: Score: 0/0

Practice Quiz — 8 Questions

SCS-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.

out of 8 correct