AWS Security Token Service
View on GitHubAWS Security Token Service
AWS Security Token Service issues temporary, limited-privilege security credentials (tokens) that applications, AWS services, and federated users can use to access AWS resources. It operates via API operations that return short‑lived credentials when callers assume an IAM role or exchange external identity tokens. STS is typically used alongside IAM and identity providers to enable cross-account access, federation, and temporary elevated privileges in an AWS architecture.
🗂 Resource Category
Security, Identity, and Compliance
🧠 Exam Memory Hook
Think: "Temporary credentials + cross-account or federated access = AWS Security Token Service"
📖 Ownership
Classification: AWS Managed Service
AWS responsibilities: AWS operates, secures, and maintains the STS control plane and service platform, including the underlying physical infrastructure and the managed runtime used to issue tokens; AWS is responsible for patching and maintaining the service components that run STS.
Customer responsibilities: The customer configures IAM roles, trust policies, permissions, session policies, token duration, and the applications or identity providers that call STS; the customer is responsible for granting least privilege, rotating long‑lived credentials used to obtain STS tokens, monitoring token use via CloudTrail and CloudWatch, and revoking or adjusting permissions as needed.
Patching responsibilities: AWS patches and maintains the physical infrastructure and the STS service platform and runtime; there is no guest operating system or customer-managed runtime to patch for STS itself, and customers are responsible for patching any EC2 instances, container hosts, application runtimes, libraries, dependencies, and customer code that call STS.
🏗 Typical Architecture
💡 Top 5 Features
- Issues temporary security credentials (access key, secret key, and session token) for IAM roles and federated identities.
- Supports role assumption APIs that enable cross-account access and role chaining when configured in trust policies.
- Accepts external identity tokens (for example SAML or web identity) to exchange for AWS credentials using federation APIs.
- Allows session policies and configurable session duration to limit privileges and lifetime of issued credentials.
- Integrates with IAM trust policies so permissions and principal trust relationships are enforced at token issuance.
✅ Top 5 Use Cases
- Enable cross-account access by allowing principals in one AWS account to assume a role in another account without long‑lived credentials.
- Provide short‑lived credentials for mobile or browser-based applications after identity federation with an external identity provider.
- Grant temporary elevated privileges to automation or CI/CD pipelines for specific tasks and then expire those privileges automatically.
- Issue temporary credentials for AWS Lambda functions or ECS tasks when using role assumption patterns in multi-account deployments.
- Allow third-party vendors or contractors limited-time access to specific resources by issuing time-bound tokens tied to an IAM role.
🏗 Architecture Placement
STS sits at the identity and access layer and is invoked by applications, identity providers, or AWS services to request temporary credentials; it normally receives calls from federated identity flows or service control processes and returns tokens that are used to access AWS resources protected by IAM. STS integrates directly with IAM role definitions and trust policies and its tokens are presented to resource endpoints such as S3, EC2, or Lambda. Depending on configuration, callers may use regional or global STS endpoints.
🎯 Commonly Used With
- AWS Identity and Access Management
- Amazon EC2
- AWS Lambda
- Amazon Cognito
- Amazon S3
🌍 5 Real-World Examples
- A financial services team configures cross-account roles and uses STS to allow deployment automation in a management account to assume roles in production accounts for controlled operations.
- A healthcare web portal exchanges a SAML assertion for temporary AWS credentials so authenticated clinicians can retrieve patient documents from S3 without long‑lived keys.
- A media processing pipeline issues temporary credentials for an external vendor to upload raw assets to a staging S3 bucket for a limited window of time.
- An education platform uses Cognito with STS to provide short‑lived access tokens to browser clients so they can upload class materials to S3 directly.
- A government audit process grants temporary console access to an external auditor by creating a role and issuing STS credentials scoped to the audit period.
🎓 AWS Exam Clues
- Use STS when exam wording requires short‑lived credentials, temporary security tokens, or time‑limited access.
- Choose STS with AssumeRole for cross-account access rather than sharing long‑lived IAM user credentials.
- Look for federation scenarios (SAML, OIDC, web identity) where the exam expects exchanging external identity tokens for AWS credentials.
- Session duration or session policies mentioned in a question typically indicate STS-based temporary credentials are required.
- When the question involves revocable, limited‑time access for third parties or automation, STS role assumption is a likely solution.
📝 Quick Revision
STS issues temporary, limited-privilege credentials used for cross-account access, federation, and short‑lived elevated privileges. Use IAM roles and trust policies to control who can assume roles, monitor usage via CloudTrail, and limit session duration for security.
🏷 Keywords
temporary credentials • AssumeRole • AssumeRoleWithSAML • AssumeRoleWithWebIdentity • GetSessionToken • GetFederationToken • session duration • session policy • trust policy • role chaining • identity federation • cross-account access