{
	"id": "2c1cf05d-1e66-40f9-861e-ad851ac230ee",
	"created_at": "2026-04-06T00:19:13.347868Z",
	"updated_at": "2026-04-10T13:11:54.612129Z",
	"deleted_at": null,
	"sha1_hash": "5bc27747b765b56f7144a41431acd85245fcf760",
	"title": "Temporary security credentials in IAM",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 73788,
	"plain_text": "Temporary security credentials in IAM\r\nArchived: 2026-04-05 23:49:37 UTC\r\nYou can use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary\r\nsecurity credentials that can control access to your AWS resources. Temporary security credentials work almost\r\nidentically to long-term access key credentials, with the following differences:\r\nTemporary security credentials are short-term, as the name implies. They can be configured to last for\r\nanywhere from a few minutes to several hours. After the credentials expire, AWS no longer recognizes\r\nthem or allows any kind of access from API requests made with them.\r\nTemporary security credentials are not stored with the user but are generated dynamically and provided to\r\nthe user when requested. When (or even before) the temporary security credentials expire, the user can\r\nrequest new credentials, as long as the user requesting them still has permissions to do so.\r\nAs a result, temporary credentials have the following advantages over long-term credentials:\r\nYou do not have to distribute or embed long-term AWS security credentials with an application.\r\nYou can provide access to your AWS resources to users without having to define an AWS identity for them.\r\nTemporary credentials are the basis for roles and identity federation.\r\nThe temporary security credentials have a limited lifetime, so you do not have to update them or explicitly\r\nrevoke them when they're no longer needed. After temporary security credentials expire, they cannot be\r\nreused. You can specify how long the credentials are valid, up to a maximum limit.\r\nAWS STS and AWS regions\r\nTemporary security credentials are generated by AWS STS. By default, AWS STS is a global service with a single\r\nendpoint at https://sts.amazonaws.com . However, you can also choose to make AWS STS API calls to\r\nendpoints in any other supported Region. This can reduce latency (server lag) by sending the requests to servers in\r\na Region that is geographically closer to you. No matter which Region your credentials come from, they work\r\nglobally. For more information, see Manage AWS STS in an AWS Region.\r\nCommon scenarios for temporary credentials\r\nTemporary credentials are useful in scenarios that involve identity federation, delegation, cross-account access,\r\nand IAM roles.\r\nIdentity federation\r\nYou can manage your user identities in an external system outside of AWS and grant users who sign in from those\r\nsystems access to perform AWS tasks and access your AWS resources. IAM supports two types of identity\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html\r\nPage 1 of 4\n\nfederation. In both cases, the identities are stored outside of AWS. The distinction is where the external system\r\nresides—in your data center or an external third party on the web. To compare features of temporary security\r\ncredentials for identity federation, see Compare AWS STS credentials.\r\nFor more information about external identity providers, see Identity providers and federation into AWS.\r\nOpenID Connect (OIDC) federation – You can let users sign in using a well-known third-party identity\r\nprovider such as Login with Amazon, Facebook, Google, or any OIDC 2.0 compatible provider for your\r\nmobile or web application, you don't need to create custom sign-in code or manage your own user\r\nidentities. Using OIDC federation helps you keep your AWS account secure, because you don't have to\r\ndistribute long-term security credentials, such as IAM user access keys, with your application. For more\r\ninformation, see OIDC federation.\r\nAWS STS OIDC federation supports Login with Amazon, Facebook, Google, and any OpenID Connect\r\n(OIDC)-compatible identity provider.\r\nNote\r\nFor mobile applications, we recommend that you use Amazon Cognito. You can use this service with AWS\r\nSDKs for mobile development to create unique identities for users and authenticate them for secure access\r\nto your AWS resources. Amazon Cognito supports the same identity providers as AWS STS, and also\r\nsupports unauthenticated (guest) access and lets you migrate user data when a user signs in. Amazon\r\nCognito also provides API operations for synchronizing user data so that it is preserved as users move\r\nbetween devices. For more information, see Authentication with Amplify in the Amplify Documentation.\r\nSAML federation – You can authenticate users in your organization's network, and then provide those\r\nusers access to AWS without creating new AWS identities for them and requiring them to sign in with\r\ndifferent sign-in credentials. This is known as the single sign-on approach to temporary access. AWS STS\r\nsupports open standards like Security Assertion Markup Language (SAML) 2.0, with which you can use\r\nMicrosoft AD FS to leverage your Microsoft Active Directory. You can also use SAML 2.0 to manage your\r\nown solution for federating user identities. For more information, see SAML 2.0 federation.\r\nCustom federation broker – You can use your organization's authentication system to grant access\r\nto AWS resources. For an example scenario, see Enable custom identity broker access to the AWS\r\nconsole.\r\nFederation using SAML 2.0 – You can use your organization's authentication system and SAML to\r\ngrant access to AWS resources. For more information and an example scenario, see SAML 2.0\r\nfederation.\r\nRoles for cross-account access\r\nMany organizations maintain more than one AWS account. Using roles and cross-account access, you can define\r\nuser identities in one account, and use those identities to access AWS resources in other accounts that belong to\r\nyour organization. This is known as the delegation approach to temporary access. For more information about\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html\r\nPage 2 of 4\n\ncreating cross-account roles, see Create a role to give permissions to an IAM user. To learn whether principals in\r\naccounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see\r\nWhat is IAM Access Analyzer?.\r\nRoles for Amazon EC2\r\nIf you run applications on Amazon EC2 instances and those applications need access to AWS resources, you can\r\nprovide temporary security credentials to your instances when you launch them. These temporary security\r\ncredentials are available to all applications that run on the instance, so you don't need to store any long-term\r\ncredentials on the instance. For more information, see Use an IAM role to grant permissions to applications\r\nrunning on Amazon EC2 instances.\r\nTo learn more about IAM Amazon EC2 role credentials, see IAM roles for Amazon EC2 in the Amazon Elastic\r\nCompute Cloud User Guide.\r\nOther AWS services\r\nYou can use temporary security credentials to access most AWS services. For a list of the services that accept\r\ntemporary security credentials, see AWS services that work with IAM.\r\nSample applications that use temporary credentials\r\nYou can use AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security\r\ncredentials that can control access to your AWS resources. For more information about AWS STS, see Temporary\r\nsecurity credentials in IAM. To see how you can use AWS STS to manage temporary security credentials, you can\r\ndownload the following sample applications that implement complete example scenarios:\r\nEnabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0. Demonstrates how\r\nto delgate access using enterprise federation to AWS using Windows Active Directory (AD), Active\r\nDirectory Federation Services (ADFS) 2.0, and SAML (Security Assertion Markup Language) 2.0.\r\nEnable custom identity broker access to the AWS console. Demonstrates how to create a custom federation\r\nproxy that enables single sign-on (SSO) so that existing Active Directory users can sign in to the AWS\r\nManagement Console.\r\nHow to Use Shibboleth for Single Sign-On to the AWS Management Console.. Shows how to use\r\nShibboleth and SAML to provide users with single sign-on (SSO) access to the AWS Management\r\nConsole.\r\nSamples for OIDC federation\r\nThe following sample applications illustrate how to use OIDCfederation with providers like Login with Amazon,\r\nAmazon Cognito, Facebook, or Google. You can trade authentication from these providers for temporary AWS\r\nsecurity credentials to access AWS services.\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html\r\nPage 3 of 4\n\nAmazon Cognito Tutorials – We recommend that you use Amazon Cognito with the AWS SDKs for mobile\r\ndevelopment. Amazon Cognito is the simplest way to manage identity for mobile apps, and it provides\r\nadditional features like synchronization and cross-device identity. For more information about Amazon\r\nCognito, see Authentication with Amplify in the Amplify Documentation.\r\nThe following scenarios and applications can guide you in using temporary security credentials:\r\nHow to integrate AWS STS SourceIdentity with your identity provider. This post shows you how to set up\r\nthe AWS STS SourceIdentity attribute when using Okta, Ping, or OneLogin as your IdP.\r\nOIDC federation. This section discusses how to configure IAM roles when you use OIDC federation and\r\nthe AssumeRoleWithWebIdentity API.\r\nSecure API access with MFA. This topic explains how to use roles to require multi-factor authentication\r\n(MFA) to protect sensitive API actions in your account.\r\nFor more information on policies and permissions in AWS see the following topics:\r\nAccess management for AWS resources\r\nPolicy evaluation logic.\r\nManaging Access Permissions to Your Amazon S3 Resources in Amazon Simple Storage Service User\r\nGuide.\r\nTo learn whether principals in accounts outside of your zone of trust (trusted organization or account) have\r\naccess to assume your roles, see What is IAM Access Analyzer?.\r\nSource: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html"
	],
	"report_names": [
		"id_credentials_temp.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434753,
	"ts_updated_at": 1775826714,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5bc27747b765b56f7144a41431acd85245fcf760.pdf",
		"text": "https://archive.orkl.eu/5bc27747b765b56f7144a41431acd85245fcf760.txt",
		"img": "https://archive.orkl.eu/5bc27747b765b56f7144a41431acd85245fcf760.jpg"
	}
}