Security practice questions

Cognito's three tokens have distinct jobs: the ID token answers "who is the user" with profile claims, the access token answers "what may this caller do", and the refresh token silently renews the other two.

Profile data like name and email lives in the ID token's claims, which is exactly what a profile screen needs. The access token is the classic confusion: it authorizes API requests via scopes and groups but does not carry profile attributes. The refresh token is opaque to the application and only ever exchanged with Cognito. A SAML assertion, when federation is involved, is consumed by the user pool during brokering — the app still receives standard Cognito JWTs.

1. Identify the need: identity information for display, not API authorization.
2. Map identity claims to the ID token and authorization to the access token.
3. Read name and email from the validated ID token's payload.
4. Continue sending the access token, not the ID token, when calling scoped APIs.

Exam tip: ID token = identity claims for the app; access token = authorization for APIs.

Cognito issues short-lived ID and access tokens (one hour by default) alongside a long-lived refresh token (30 days by default) whose only job is renewing the other two against Cognito without re-login.

Silent renewal with the refresh token keeps sessions alive while access tokens stay short-lived — the intended design. Stretching access token validity to 30 days is impossible (24-hour maximum) and would be poor practice even if allowed, because bearer tokens grant access to whoever holds them. Sending the refresh token to the API misroutes it — it is only valid against Cognito. Storing passwords locally to re-authenticate is a textbook credential-handling failure.

1. Keep ID and access token lifetimes short — that is a security feature, not a bug.
2. Hold the refresh token securely on the client.
3. Before or upon expiry, exchange the refresh token with Cognito for new ID and access tokens.
4. Force full re-authentication only when the refresh token itself expires or is revoked.

Exam tip: Session longevity comes from the refresh token exchanged with Cognito — never from long-lived access tokens or stored passwords.

A JWT has three parts — header, payload, signature — and its trustworthiness rests entirely on verifying the signature against the issuer's public keys, plus validating standard claims such as expiry and issuer.

The backend must verify the signature using the user pool's JWKS endpoint and check that exp has not passed, iss matches the expected user pool, and the audience/token_use fit the context. Merely decoding the payload accepts forged tokens. Storing tokens in a database for comparison misunderstands bearer tokens — they are stateless and verified with cryptography, not lookups. STS is a credential-minting service and plays no role in JWT validation.

1. Fetch and cache the user pool's public keys from its JWKS endpoint.
2. Verify the token signature with the key identified by the token header's key ID.
3. Validate exp (not expired), iss (correct user pool), and the audience or token_use claim.
4. Only then read claims such as sub and cognito:groups to make authorization decisions.

Exam tip: Trust a JWT only after verifying its signature against the issuer's JWKS and validating expiry and issuer — decoding alone proves nothing.

A Cognito user pool can broker federation: external SAML 2.0, OIDC, and social providers are registered with the pool, and after any of them authenticates the user, the pool issues its own standard JWTs.

The requirement is a single, consistent token format regardless of provider — exactly what user pool brokering delivers, and adding a social provider later is just another IdP registration. Migrating accounts duplicates identities and passwords the company already manages, the classic anti-pattern when a scenario says employees "already authenticate" somewhere. An identity pool federates too, but its output is temporary AWS credentials, not an application JWT. Per-employee IAM users confuse AWS access management with application authentication.

1. Register the corporate SAML IdP with the Cognito user pool.
2. Have employees sign in through the provider via the user pool's sign-in flow.
3. Let the user pool normalize the response and issue ID, access, and refresh JWTs.
4. Validate those Cognito JWTs in the API — the same code path for any future social provider.

Exam tip: An existing corporate IdP means federate through a user pool as broker — one JWT format out, no duplicated accounts.

sts:AssumeRole requires two allows: the role's trust policy (a resource-based policy) must name the caller as a principal, and the caller's identity-based policy must permit sts:AssumeRole on the role's ARN.

The stem establishes the trust-policy side is already correct, so the remaining failure point is the caller's side: the developer's identity in account A needs an explicit allow for sts:AssumeRole on the role's ARN. An instance profile only matters for EC2-attached roles. Creating an IAM user in account B contradicts the whole point of cross-account roles. The role's own permissions policy determines what the assumed session can do, never who can assume it.

1. Confirm the trust policy in account B names the account A principal and allows sts:AssumeRole.
2. Check the caller's identity-based policy in account A for an allow on sts:AssumeRole with the role's ARN.
3. Add the missing allow scoped to that specific role ARN.
4. Retry AssumeRole and use the returned temporary credentials in account B.

Exam tip: AssumeRole failures are two-sided: verify the role's trust policy AND the caller's sts:AssumeRole permission — a correct trust policy alone is not enough.

AWS SDKs resolve credentials through the credential provider chain, checking sources in a fixed order — explicit configuration, environment variables, the shared credentials file, web identity, container credentials, then the EC2 instance metadata service — and stopping at the first hit.

Because environment variables precede the instance metadata service in the chain, the leftover AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY silently outrank the attached role — and since that user is deactivated, calls fail with an error naming it. Nothing needs to be loaded in code for a role to work, the platform refreshes role credentials automatically, and there is no rule preventing roles from coexisting with environment variables — precedence, not compatibility, is the problem.

1. Read the error: it names a deactivated IAM user, not the instance role — some other credential source is winning.
2. Recall the chain order: environment variables come before the instance metadata service.
3. Unset AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY on the instance.
4. Confirm the SDK now falls through to the instance role's temporary credentials.

Exam tip: The credential provider chain stops at the first match — stale environment-variable keys silently override an attached instance role.