# AWS security credentials When you interact with AWS, you specify your AWS *security credentials* to verify who you are and whether you have permission to access the resources that you are requesting. AWS uses the security credentials to authenticate and authorize your requests. For example, if you want to download a protected file from an Amazon Simple Storage Service (Amazon S3) bucket, your credentials must allow that access. If your credentials don't show you are authorized to download the file, AWS denies your request. However, your AWS security credentials aren't required for you to download a file in an Amazon S3 bucket that is publicly shared. There are different types of users in AWS, each with their own security credentials: + **Account owner (root user)** — The user who created the AWS account and has full access. + **AWS IAM Identity Center users** — Users managed in AWS IAM Identity Center. + **Federated principals** — Users from external identity providers who are granted temporary access to AWS through federation. For more information about federated identities, see [Identity providers and federation into AWS](id_roles_providers.md). + **IAM users** — Individual users created within the AWS Identity and Access Management (IAM) service. Users have either long-term or temporary security credentials. Root user, IAM user, and access keys have long-term security credentials that do not expire. To protect long-term credentials have processes in place to [manage access keys](id_credentials_access-keys.md), [change passwords](id_credentials_passwords.md), and [enable MFA](id_credentials_mfa.md). To simplify managing root user credentials across member accounts in AWS Organizations, you can centrally secure the root user credentials of your AWS accounts managed using AWS Organizations. [Centrally manage root access for member accounts](id_root-user.md#id_root-user-access-management) lets you centrally remove and prevent long-term root user credential recovery, preventing unintended root access at scale. IAM roles, users in AWS IAM Identity Center, and AWS STS federated user principals have temporary security credentials. Temporary security credentials expire after a defined period of time or when the user ends their session. Temporary credentials work almost identically to long-term credentials, with the following differences: + Temporary security credentials are *short-term*, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them. + Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials, as long as the user requesting them still has permissions to do so. As a result, temporary credentials have the following advantages over long-term credentials: + You do not have to distribute or embed long-term AWS security credentials with an application. + You can provide access to your AWS resources to users without having to define an AWS identity for them. Temporary credentials are the basis for [roles and identity federation](id_roles.md). + The temporary security credentials have a limited lifetime, so you do not have to update them or explicitly revoke them when they're no longer needed. After temporary security credentials expire, they cannot be reused. You can specify how long the credentials are valid, up to a maximum limit. ## Security considerations We recommend that you consider the following information when determining the security provisions for your AWS account: + When you create an AWS account, we create the account root user. The credentials of the root user (account owner) allow full access to all resources in the account. The first task you perform with the root user is to grant another user administrative permissions to your AWS account so that you minimize the usage of the root user. + Multi-factor authentication (MFA) provides an extra level of security for users who can access your AWS account. For additional security, we recommend that you require MFA on the AWS account root user credentials and all IAM users. For more information, see [AWS Multi-factor authentication in IAM](id_credentials_mfa.md). + AWS requires different types of security credentials, depending on how you access AWS and what type of AWS user you are. For example, you use sign-in credentials for the AWS Management Console while you use access keys to make programmatic calls to AWS. For help determining your user type and sign-in page, see [What is AWS Sign-In](https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html) in the *AWS Sign-In User Guide*. + You can't use IAM policies to deny the root user access to resources explicitly. You can only use an AWS Organizations [service control policy (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_type-auth.html) to limit the permissions of the root user. + If you forget or lose your root user password, you must have access to the email address associated with your account in order to reset it. + If you lose your root user access keys, you must be able to sign in to your account as the root user to create new ones. + Do not use the root user for your everyday tasks. Use it to perform the tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](id_root-user.md#root-user-tasks). + Security credentials are account-specific. If you have access to multiple AWS accounts, you have separate credentials for each account. + [Policies](access_policies.md) determine what actions a user, role, or member of a user group can perform, on which AWS resources, and under what conditions. Using policies you can securely control access to AWS services and resources in your AWS account. If you must modify or revoke permissions in response to a security event, you delete or modify the policies instead of making changes directly to the identity. + Be sure to save the sign-in credentials for your *Emergency Access* IAM user and any access keys you created for programmatic access in a secure location. If you lose your access keys, you must sign in to your account to create new ones. + We strongly recommend that you use temporary credentials provided by IAM roles and federated principals instead of the long-term credentials provided by IAM users and access keys. # Programmatic access with AWS security credentials Programmatic access We recommend using short-term access keys when possible to make programmatic calls to AWS or to use the AWS Command Line Interface or AWS Tools for PowerShell. However, you can also use long-term AWS access keys for these purposes. When you create a long-term access key, you create the access key ID (for example, `AKIAIOSFODNN7EXAMPLE`) and secret access key (for example, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`) as a set. The secret access key is available for download only when you create it. If you don't download your secret access key or if you lose it, you must create a new one. In many scenarios, you don't need long-term access keys that never expire (as you have when you create access keys for an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials include an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire. After they expire, they're no longer valid. For more information, see [Alternatives to long-term access keys](#security-creds-alternatives-to-long-term-access-keys) Access key IDs beginning with `AKIA` are long-term access keys for an IAM user or an AWS account root user. Access key IDs beginning with `ASIA` are temporary credentials access keys that you create using AWS STS operations. Users need programmatic access if they want to interact with AWS outside of the AWS Management Console. The way to grant programmatic access depends on the type of user that's accessing AWS. To grant users programmatic access, choose one of the following options. **** | Which user needs programmatic access? | To | By | | --- | --- | --- | | IAM | (Recommended) Use console credentials as temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds-programmatic-access.html) | | Workforce identity (Users managed in IAM Identity Center) | Use temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds-programmatic-access.html) | | IAM | Use temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions in [Using temporary credentials with AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) in the IAM User Guide. | | IAM | (Not recommended)Use long-term credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds-programmatic-access.html) | ## Alternatives to long-term access keys For many common use cases, there are alternatives to long-term access keys. To improve your account security, consider the following. + **Don't embed long-term access keys and secret access keys in your application code or in a code repository –** Instead, use AWS Secrets Manager, or other secrets management solution, so you don't have to hardcode keys in plaintext. The application or client can then retrieve secrets when needed. For more information, see [What is AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) in the *AWS Secrets Manager User Guide*. + ** Use IAM roles to generate temporary security credentials whenever possible –** Always use mechanisms to issue temporary security credentials when possible, rather than long-term access keys. Temporary security credentials are more secure because they are not stored with the user but are generated dynamically and provided to the user when requested. Temporary security credentials have a limited lifetime so you don't have to manage or update them. Mechanisms that provide temporary access keys include IAM roles or the authentication of an IAM Identity Center user. For machines that run outside of AWS you can use [AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). + ** Use alternatives to long-term access keys for the AWS Command Line Interface (AWS CLI) or the `aws-shell` –** Alternatives include the following. + **Login for AWS local development with console credentials**. You can use the AWS CLI Version 2 and the `aws login` command to generate short-term credentials to run AWS CLI commands using your console credentials. To learn more, see [Login for AWS local development](https://docs.aws.amazon.com//cli/latest/userguide/cli-authentication-user.html) in the *AWS Command Line Interface User Guide*. + **AWS CloudShell** is a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console. You can run AWS CLI commands against AWS services through your preferred shell (Bash, Powershell, or Z shell). When you do this, you don't need to download or install command line tools. For more information, see [What is AWS CloudShell?](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) in the *AWS CloudShell User Guide*. + **Don't create long-term access keys for human users who need access to applications or AWS services –** IAM Identity Center can generate temporary access credentials for your external IdP users to access AWS services. This eliminates the need to create and manage long-term credentials in IAM. In IAM Identity Center, create an IAM Identity Center permission set that grants the external IdP users access. Then assign a group from IAM Identity Center to the permission set in the selected AWS accounts. For more information, see [What is AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html), [Connect to your external identity provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html), and [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center User Guide*. + **Don't store long-term access keys within an AWS compute service –** Instead, assign an IAM role to compute resources. This automatically supplies temporary credentials to grant access. For example, when you create an instance profile that is attached to an Amazon EC2 instance, you can assign an AWS role to the instance and make it available to all of its applications. An instance profile contains the role and enables programs that are running on the Amazon EC2 instance to get temporary credentials. To learn more, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).