beginnerintermediateadvanced

AWS · Authentication and Federation

AWS Authentication and Federation

How a person or workload ends up with a working, temporary AWS session — never a standing personal key

One federation pointIAM Identity Center for workforce access across accounts
ASIA beats AKIAtemporary role credentials over long-lived IAM user keys
MFA on humans, roles on workloadsnever the other way around
Chain stops at the first matchenv vars, config file, SSO, container, IMDS

1.IAM Identity Center and federated access

IAM Identity Center is one central point where workforce users sign in once and get access to multiple AWS accounts and applications, instead of each account managing its own separate set of IAM users.

Key features

One federation point instead of one IAM user per AWS account
Connects to an external identity provider or manages users directly
An organization instance manages access across every account in AWS Organizations
Users reach assigned accounts through the AWS access portal
Existing IAM federation setups keep working unchanged alongside it

One sign-in, many accounts

users +groupsfederatedaccess

Identity provider

Okta, Entra ID, or built-in

IAM Identity Center

one federation point

AWS accounts

permission sets assign access

Command

text

Identity provider (Okta, Entra ID, ...)
        │  users + groups synced
        ▼
IAM Identity Center  →  permission sets  →  AWS accounts

IAM Identity Center is one federation point for workforce access across multiple AWS accounts and applications — not a replacement requirement for working IAM federation.

2.SAML and OIDC federation

SAML and OIDC are two different standards for the same job: proving who a user or workload is to AWS without AWS ever seeing a password, then exchanging that proof for temporary AWS credentials.

Key features

SAML: XML assertions, common for workforce SSO (Okta, Entra ID, ADFS)
OIDC: JSON Web Tokens (JWT), common for CI/CD and machine identities
Both end the same way — a JWT or assertion exchanged for temporary AWS credentials
GitHub Actions authenticating to AWS is the canonical OIDC example
IAM applies a 5-minute clock-skew window past a JWT's stated expiry

Command

text

SAML: IdP → SAML assertion (XML) → AssumeRoleWithSAML → temp creds
OIDC: IdP → JWT (JSON)         → AssumeRoleWithWebIdentity → temp creds

SAML and OIDC are two token formats for the same exchange — prove identity externally, then trade the proof for temporary AWS credentials via AssumeRoleWithSAML or AssumeRoleWithWebIdentity.

3.Role assumption and short-lived credentials

Assuming a role means trading proof of who you are for a temporary access key, secret key, and session token that expire on their own — no key to store, revoke, or accidentally leak permanently.

Key features

STS AssumeRole returns access key + secret key + session token
Credentials expire automatically — 15 minutes to 12 hours, role-dependent
No revocation step needed — expiry does the work on its own
A temporary access key starts with ASIA; a long-lived IAM user key starts with AKIA
SDKs refresh temporary credentials automatically before they expire

Long-lived IAM user key vs. temporary role credentials

Long-lived IAM user key vs. temporary role credentials
Property	IAM user access key	Assumed-role credentials
Key prefix	AKIA...	ASIA...
Expires	Never, until manually deleted	Automatically, 15 min – 12 hr
Revocation	Manual — delete or deactivate the key	Not needed — it stops working on its own
Typical use	Rare — break-glass, legacy tooling	Default — humans and workloads alike

Assuming a role

Caller

STS

Target role

1AssumeRole(role_arn)
2checks trust policy
3temporary credentials (ASIA...)
4credentials expire automatically15 min – 12 hr later

Command

text

sts:AssumeRole(role_arn, session_name) → { AccessKeyId, SecretAccessKey, SessionToken, Expiration }

An assumed role returns temporary credentials that expire automatically (15 min–12 hr) — the ASIA prefix versus AKIA is the fastest way to tell temporary from long-lived at a glance.

4.The SDK/CLI credential provider chain

Every AWS SDK and the CLI check a fixed, ordered list of places for credentials — environment variables, config files, container metadata, EC2 instance role — and stop at the first one that has valid credentials.

Key features

The search stops at the first source with valid credentials
Static AWS access keys are one source among several, not the only one
On EC2, the IMDS provider supplies credentials from the attached instance role
On ECS/EKS, the container credential provider does the equivalent job
Credentials found via a temporary-credential provider are refreshed automatically before expiry

Common credential sources, roughly in the order most SDKs check them

Common credential sources, roughly in the order most SDKs check them
Source	Typical use
Explicit in code	Rare — hardcoding is discouraged
Environment variables	AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, CI runners
Shared config/credentials file	~/.aws/credentials, local development, named profiles
SSO / IAM Identity Center	aws configure sso, workforce access
Assume role provider	A profile configured to assume another role
Container credential provider	ECS tasks, EKS pods with IAM roles for service accounts
IMDS (instance metadata)	EC2 instances with an attached instance profile role

Command

text

code > env vars > shared config file > SSO > assume-role provider > container provider > IMDS

The credential provider chain stops at the first source with valid credentials, in a fixed order — a stray environment variable is the most common reason the "wrong" identity gets used.

5.MFA, root protection, and workload identity

Human sign-ins should require MFA (ideally a phishing-resistant kind, like a hardware security key), the root user should be locked away for emergencies only, and a running application should authenticate as its own workload identity — never as a person.

Key features

Phishing-resistant MFA (FIDO2/WebAuthn security keys) resists what SMS/OTP codes do not — a fake login page relaying the code in real time
Root should have MFA enabled and be used only for account-level emergency tasks
A workload gets an IAM role, not a person's IAM user credentials
A person leaving the company should never mean an application stops working
MFA is enforced per-identity, and can be required as a policy Condition too

Three identities, three different protections

Human sign-in

phishing-resistant MFA (FIDO2 key)

Root user

MFA-locked, emergency-only

Application workload

IAM role, never a person's credentials

Command

text

aws:MultiFactorAuthPresent (policy condition) — true only inside an MFA-authenticated session

MFA protects human sign-in (phishing-resistant where possible), root is emergency-only, and a workload authenticates as itself via a role — never by borrowing a person's credentials.

Spotted a mistake on this page? Tell us.

Read Sheet