5.1.1. Identity Solutions (IAM Identity Center, Cognito, MFA)

First Principle: Different identity consumers — humans, customer-facing applications, and system integrations — require different authentication mechanisms. Using the wrong mechanism for the context creates either security gaps or unnecessary friction.

AWS IAM Identity Center (successor to AWS SSO):

• Purpose: Centralized human access to AWS accounts and cloud applications
• How it works: Users authenticate once through Identity Center, then access any assigned AWS account or application via permission sets
• Identity sources: Built-in directory, Active Directory (AD Connector or AWS Managed AD), or external IdP (Okta, Microsoft Entra ID) via SAML 2.0
• Permission sets: Define what users can do in each account — map to IAM roles created automatically in target accounts; access is an assignment of (user or group, permission set, account), so one group can hold different permission sets in different accounts
• Automatic provisioning (SCIM): SAML only authenticates users; to sync users and groups from an external IdP (Okta, Microsoft Entra ID) into Identity Center automatically, enable SCIM provisioning — without it, users must be created in Identity Center manually
• Attributes for access control: map IdP attributes (e.g., cost center or team), passed in the SAML assertion or synced via SCIM, into session tags and reference them with aws:PrincipalTag conditions in permission set policies (ABAC)
• Best for: employee access to AWS console and CLI across multi-account environments

Amazon Cognito:

• Purpose: Authentication for external users (customers, mobile app users, web app users)
• User Pools: User directory with sign-up, sign-in (local accounts or federated social, SAML, and OIDC providers), and MFA. Issues JWT tokens.
• Identity Pools: Exchange tokens for temporary AWS credentials (IAM roles). Supports federation with social IdPs (Google, Apple, Facebook) or SAML IdPs.
• Authenticated vs. guest roles: an identity pool assigns one IAM role to authenticated identities and, optionally, another to unauthenticated guests — anyone can obtain guest credentials, so scope that role to the bare minimum. Without an identity pool, user pool sign-in yields only JWTs, not AWS credentials.
• Threat protection (formerly advanced security features): detects compromised credentials and risky sign-ins such as credential stuffing, and applies adaptive authentication — allow, require MFA, or block
• Best for: customer-facing applications where you can't use IAM Identity Center

Multi-Factor Authentication (MFA):

• Virtual MFA: TOTP apps (Authenticator apps) — most common, lowest cost
• Hardware MFA: Physical token devices — required for root account (recommended)
• FIDO2 Security Keys: Phishing-resistant hardware keys (YubiKey) — strongest MFA; the key's response is bound to the site's origin, so a phishing site can't capture a reusable code
• Passkeys: Built-in FIDO2 support using device biometrics — newest option
• Not supported for IAM: SMS or email codes and standalone biometric readers — IAM MFA is limited to passkeys/FIDO2 security keys, virtual authenticator apps, and hardware TOTP tokens

When to Use Which:

⚠️ Exam Trap: IAM Identity Center is for human workforce access. Cognito is for external application users. If a question describes "employees accessing multiple AWS accounts," the answer is Identity Center, not Cognito.

Scenario: A company migrating from on-premises Active Directory needs employees to access 50 AWS accounts without creating IAM users. They deploy IAM Identity Center connected to their AD via AD Connector, create permission sets for each role type (admin, developer, auditor), and require FIDO2 MFA.

Reflection Question: Why does AWS recommend IAM Identity Center over creating IAM users in each account, and what security properties does federation provide that per-account users don't?