AWS Authentication and Federation

What we're doing: See what an engineer actually does to reach an AWS account through Identity Center, versus a standalone IAM user in each account.

# Federated (IAM Identity Center)
1. Sign in once at the AWS access portal
2. Pick an assigned account + permission set
3. Get temporary credentials for that account

# Without federation (per-account IAM users)
5. A separate IAM user, password, and MFA device — per account
6. No single place to revoke access across all of them at once

1

One sign-in, one identity provider — the login event happens exactly once.

3

Credentials are temporary, scoped to the chosen account and permission set, not a standing IAM user.

5

Every account needs its own user and its own credential lifecycle to manage separately.

6

Offboarding someone means finding and disabling every one of those per-account users individually.

Why this works: Federation moves "who has access to what" into one place that can be audited and revoked centrally, instead of scattered per-account IAM users that each need separate lifecycle management.

What we're doing: Compare the two token formats AWS accepts for federation, side by side.

{
  "iss": "https://token.actions.githubusercontent.com",
  "sub": "repo:my-org/my-repo:ref:refs/heads/main",
  "exp": 1735689600,
  "aud": "sts.amazonaws.com"
}

3

"sub" is what a trust policy Condition typically matches against — here, a specific repo and branch.

4

"exp" is the token's stated expiry; IAM accepts it up to 5 minutes past this for clock skew.

Why this works: A workload never holds a long-lived AWS key at all — it presents this JWT to sts:AssumeRoleWithWebIdentity, and the trust policy's Condition on "sub" decides which repo/branch is allowed to assume the role.

What we're doing: See what a caller actually receives from AssumeRole, and how short its life is by comparison to an IAM user key.

{
  "Credentials": {
    "AccessKeyId": "ASIAEXAMPLE123456789",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/...",
    "SessionToken": "FQoGZXIvYXdzELr//////...",
    "Expiration": "2026-08-21T15:45:00Z"
  }
}

3

ASIA prefix — this key is temporary. A long-lived IAM user key would start with AKIA instead.

6

Expiration is set at assumption time, typically an hour out — after this, the credentials simply stop working.

Why this works: The AccessKeyId prefix alone tells you whether you are looking at a credential that needs active revocation (AKIA) or one that will disable itself (ASIA) — worth checking before assuming the worst during an incident.

What we're doing: Trace which credential source actually wins when more than one is present.

export AWS_ACCESS_KEY_ID=AKIAEXAMPLE
export AWS_SECRET_ACCESS_KEY=examplesecret

# ~/.aws/credentials also has a [default] profile with different keys

aws sts get-caller-identity

1

Environment variables are checked before the shared credentials file in the standard chain.

6

This call resolves to the environment-variable keys, not [default] in the credentials file — even though both exist.

Why this works: When credentials look "wrong" and nothing was obviously changed, the usual cause is a higher-priority source in the chain (often a stray environment variable from an earlier `export`) silently winning over the one being edited.

What we're doing: See an IAM policy condition that requires MFA before a sensitive action, versus one that does not check at all.

{
  "Effect": "Allow",
  "Action": "s3:DeleteObject",
  "Resource": "arn:aws:s3:::backups/*",
  "Condition": {
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

5

Without this Condition block, the Allow above would grant delete access to anyone matching the identity, MFA or not.

6

aws:MultiFactorAuthPresent is only "true" inside a session established with a verified MFA device.

Why this works: A policy allowing an action does not mean MFA was used to get there unless a Condition explicitly checks for it — MFA on sign-in and MFA-gated actions are two different, independently configured protections.