IAM, STS and Cognito

Three services carry most of the identity work on AWS:

• IAM — access control for AWS resources
• AWS STS — temporary credentials for principals and federated users
• Amazon Cognito — authentication for the end users of an application

IAM core components

Identity-based and resource-based policies

• Identity-based policies attach to IAM users, groups and roles, and define what those identities may do and to which resources.
• Resource-based policies attach to a resource — an S3 bucket, an SQS queue, a KMS key — and define who may access it. They must name a Principal.

Cross-account access requires both sides to agree: the caller’s identity-based policy must allow the action, and the resource’s policy (or the assumed role’s trust policy) must accept the caller.

Policy structure

Policies are JSON documents built from:

• Effect — Allow or Deny. An explicit Deny always wins.
• Action — the service-namespaced operations, such as s3:GetObject
• Resource — the ARNs the statement applies to
• Condition — optional context that must hold: MFA present, source address, request Region, resource tag

See IAM policy types and evaluation.

AWS Security Token Service (STS)

STS issues short-term credentials for IAM principals and for federated users. Each set consists of an access key ID, a secret access key and a session token, and expires at a defined time.

• Supports federation with external identity providers
• Enables cross-account access through role assumption
• Short-lived credentials limit the value of a leaked one

Common operations

Operation	Used for
AssumeRole	Cross-account access, and any principal switching into a role
AssumeRoleWithWebIdentity	OIDC federation — Cognito, Google, GitHub Actions and other OIDC providers
AssumeRoleWithSAML	SAML 2.0 federation, such as AD FS
GetSessionToken	Temporary credentials for an IAM user, typically to satisfy an MFA condition

See AWS Security Token Service.

Federation through an identity broker

The classic pattern for letting corporate users reach AWS without IAM users, and the model that IAM Identity Center now packages:

sequenceDiagram autonumber actor User participant App as Application participant Broker as Identity broker participant Dir as Corporate directory participant STS as AWS STS participant AWS as AWS services User->>App: Request access App->>Broker: Authenticate this user Broker->>Dir: Validate credentials Dir-->>Broker: Identity and group membership Broker->>STS: AssumeRole for the role mapped to those groups STS-->>Broker: Temporary credentials Broker-->>App: Temporary credentials App->>AWS: Call AWS services with those credentials

The corporate directory remains the source of truth, no IAM user is created for anyone, and the credentials the application holds expire on their own. For a workforce spanning many accounts, use IAM Identity Center rather than building this: it supplies the broker, the role mapping and the access portal. See IAM Identity Center integration with Active Directory.

Amazon Cognito

Cognito handles authentication and authorization for the users of a web or mobile application:

• Sign-up, sign-in, password reset and profile management
• Federation with social providers, SAML 2.0 providers and OIDC providers
• MFA and adaptive authentication
• Scalable user directories that can synchronise with enterprise identity providers
• OAuth 2.0 and OpenID Connect support
• Direct integration with API Gateway authorizers and with AWS services through identity pools

It suits serverless applications and any case where building an authentication system is not the point of the product. It suits less well where the authentication flow itself is highly customised, or where enterprise identity requirements dominate — those usually belong with an external identity provider federated into Cognito, or with IAM Identity Center.

See Amazon Cognito.

Cognito and the token vending machine pattern

Before Cognito, mobile applications that needed AWS access used a token vending machine: a service the application called to obtain temporary AWS credentials, in either an anonymous mode (AWS service access with no stored user identity) or an identity mode (registration, sign-in and per-user authorization). Cognito identity pools do exactly this as a managed service, and there is no longer a reason to build one. The pattern is worth recognising because it still appears in older architectures and documentation.

Secrets and keys

Credentials that an application needs at runtime do not belong in IAM. They belong in AWS Secrets Manager or Systems Manager Parameter Store, with the application’s IAM role granting access to them — see AWS Secrets Manager and Secrets Manager vs Parameter Store.

Practice

• Write fine-grained IAM policies: specific actions, specific resource ARNs
• Use roles and temporary credentials in place of access keys wherever possible
• Rotate what genuinely cannot be replaced by a role, on a schedule that is enforced
• Monitor access through CloudTrail, and alarm on unusual role assumption
• Audit stored secrets and cross-account grants regularly; IAM Access Analyzer reports the latter