IAM identities and credentials
The identities managed in Amazon Identity and Access Management are IAM users, IAM roles, and IAM groups. These identities are in addition to your root user that Amazon created along with your Amazon Web Services account.
We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, provision additional users and grant them the permissions required to perform the necessary tasks. You can add users either by adding people to your IAM Identity Center directory, federating an external identity provider with either IAM Identity Center or IAM or creating least privilege IAM users.
Important
In the Beijing and Ningxia Regions, there is no concept of a root user. All users are IAM users, including the user who created the Amazon account.
After you have set up your users, you can give access to your Amazon Web Services account to specific people and provide them permissions to access resources.
As a best practice, Amazon recommends that you require human users to assume an IAM role to access Amazon so that they're using temporary credentials. If you are managing identities in the IAM Identity Center directory or using federation with an identity provider you are following best practices.
Terms
These terms are commonly used when working with IAM identities:
- IAM Resource
-
The IAM service stores these resources. You can add, edit, and remove them from the IAM console.
-
IAM user
-
IAM group
-
IAM role
-
Permission policy
-
Identity-provider object
-
- IAM Entity
-
IAM resources that Amazon uses for authentication. Specify the entity as a Principal in a resource-based policy.
-
IAM user
-
IAM role
-
- IAM Identity
-
The IAM resource that's authorized in policies to perform actions and to access resources. Identities include IAM users, IAM groups, and IAM roles.
- Principals
-
An Amazon Web Services account root user, IAM user or an IAM role that can make a request for an action or operation on an Amazon resource. Principals include human users, workloads, federated users and assumed roles. After authentication, IAM grants the principal either permanent or temporary credentials to make requests to Amazon, depending on the principal type.
Human users are also known as human identities, such as the people, administrators, developers, operators, and consumers of your applications.
Workloads are a collection of resources and code that delivers business value, such as an application, process, operational tools, and other components.
Federated users are users whose identity and credentials are managed by another identity provider, such as Active Directory, Okta, or Microsoft Entra.
IAM roles are an IAM identity that you can create in your account that has specific permissions that determine what the identity can and can't do. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
IAM grants IAM users and the root user long-term credentials and IAM roles temporary credentials. Federated users and users in Amazon IAM Identity Center assume IAM roles when they sign-in to Amazon, which grants them temporary credentials. As a best practice, we recommend that you require human users and workloads to access Amazon resources using temporary credentials.
Difference between IAM users and users in IAM Identity Center
IAM users aren't separate accounts; they're individual users within your account. Each user has their own password for access to the Amazon Web Services Management Console. You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.
IAM users and their access keys have long-term credentials to your Amazon resources. The primary use for IAM users is to give workloads that can't use IAM roles the ability to make programmatic requests to Amazon services using the API or CLI.
Note
For scenarios in which you need IAM users with programmatic access and long-term credentials, we recommend that you update access keys when needed. For more information, see Updating access keys.
Workforce identities (people) are users in Amazon IAM Identity Center that have different permission needs depending on the role they're performing and can work in various Amazon Web Services accounts across an organization. If you have use cases that require access keys, you can support those use cases with users in Amazon IAM Identity Center. People who sign-in through the Amazon Web Services access portal can obtain access keys with short-term credentials to your Amazon resources. For centralized access management, we recommend that you use Amazon IAM Identity Center (IAM Identity Center) to manage access to your accounts and permissions within those accounts. IAM Identity Center is automatically configured with an Identity Center directory as your default identity source where you can add people and groups, and assign their level of access to your Amazon resources. For more information, see What is Amazon IAM Identity Center in the Amazon IAM Identity Center User Guide.
The main difference between these two types of users is that users in IAM Identity Center automatically assume an IAM role when they sign-in to Amazon before they access the management console or Amazon resources. IAM roles grant temporary credentials each time the user signs-in to Amazon. For IAM users to sign in using an IAM role they must have permission to assume and switch roles and they must explicitly choose to switch to the role they want to assume after accessing the Amazon account.
Federate users from an existing identity source
If the users in your organization are already authenticated when they sign in to your corporate network, you don't have to create separate IAM users or users in IAM Identity Center for them. Instead, you can federate those user identities into Amazon using either IAM or Amazon IAM Identity Center. Federated users assume an IAM role that gives them permissions to access specific resources. For more information about roles, see Roles terms and concepts.
Federation is useful in these cases:
-
Your users already exist in a corporate directory.
If your corporate directory is compatible with Security Assertion Markup Language 2.0 (SAML 2.0), you can configure your corporate directory to provide single-sign on (SSO) access to the Amazon Web Services Management Console for your users. For more information, see Common scenarios for temporary credentials.
If your corporate directory isn't compatible with SAML 2.0, you can create an identity broker application to provide single-sign on (SSO) access to the Amazon Web Services Management Console for your users. For more information, see Enabling custom identity broker access to the Amazon console.
If your corporate directory is Microsoft Active Directory, you can use Amazon IAM Identity Center to connect a self-managed directory in Active Directory or a directory in Amazon Directory Service
to establish trust between your corporate directory and your Amazon Web Services account. If you are using an external identity provider (IdP) such as Okta or Microsoft Entra to manage users, you can use Amazon IAM Identity Center to establish trust between your IdP and your Amazon Web Services account. For more information, see Connect to an external identity provider in the Amazon IAM Identity Center User Guide.
-
Your users already have Internet identities.
If you are creating a mobile app or web-based app that can let users identify themselves through an Internet identity provider like Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC) compatible identity provider, the app can use federation to access Amazon. For more information, see OIDC federation.
Tip
To use identity federation with Internet identity providers, we recommend you use Amazon Cognito.
Different methods to provide user access
Here are the ways you can provide access to your Amazon resources.
| Type of user access | When is it used? | Where is more information? |
|---|---|---|
|
Single sign-on access for people, such as your workforce users, to Amazon resources using IAM Identity Center |
IAM Identity Center provides a central place that brings together administration of users and their access to Amazon Web Services accounts and cloud applications. You can set up an identity store within IAM Identity Center or you can configure federation with an existing identity provider (IdP). Security best practices recommend granting your human users limited credentials to Amazon resources. People have an easier sign-in experience and you maintain control over their access to resources from a single system. IAM Identity Center supports multi-factor authentication (MFA) for additional account security. |
For more information about setting up IAM Identity Center, see Getting Started in the Amazon IAM Identity Center User Guide For more information about using MFA in IAM Identity Center, see Multi-factor authentication in the Amazon IAM Identity Center User Guide |
Federated access for human users, such as your workforce users, to Amazon services using IAM identity providers (IdPs) |
IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0). After you create an IAM identity provider, create one or more IAM roles that can be dynamically assigned to a federated user. |
For more information about IAM identity providers and federation, see Identity providers and federation. |
|
Cross-account access between Amazon Web Services accounts |
You want to share access to certain Amazon resources with users in other Amazon Web Services accounts. Roles are the primary way to grant cross-account access. However, some Amazon services support resource-based policies that allow you to attach a policy directly to a resource (instead of using a role as a proxy). |
For more information about IAM roles, see IAM roles. For more information about service-linked roles, see Using service-linked roles. For information about which services support using service-linked roles, see Amazon services that work with IAM. Find the services that have Yes in the Service-Linked Role column. To view the service-linked role documentation for that service select the link associated with the Yes in that column. |
|
Long-term credentials for designated IAM users in your Amazon Web Services account |
You might have specific use cases that require long-term credentials with IAM users in Amazon. You can use IAM to create these IAM users in your Amazon Web Services account, and use IAM to manage their permissions. Some use cases include the following:
As a best practice in scenarios in which you need IAM users with programmatic access and long-term credentials, we recommend that you update access keys when needed. For more information, see Updating access keys. |
For more information about setting up an IAM user, see Creating an IAM user in your Amazon Web Services account. For more information about IAM user access keys, see Managing access keys for IAM users. For more information about service-specific credentials for Amazon CodeCommit or Amazon Keyspaces, see Using IAM with CodeCommit: Git credentials, SSH keys, and Amazon access keys and Using IAM with Amazon Keyspaces (for Apache Cassandra). |
Support programmatic user access
Users need programmatic access if they want to interact with Amazon outside of the Amazon Web Services Management Console. The way to grant programmatic access depends on the type of user that's accessing Amazon:
-
If you manage identities in IAM Identity Center, the Amazon APIs require a profile, and the Amazon Command Line Interface requires a profile or an environment variable.
-
If you have IAM users, the Amazon APIs and the Amazon Command Line Interface require access keys. Whenever possible, create temporary credentials that consist of an access key ID, a secret access key, and a security token that indicates when the credentials expire.
To grant users programmatic access, choose one of the following options.
| Which user needs programmatic access? | Option | More information |
|---|---|---|
|
Workforce identities (People and users managed in IAM Identity Center) |
Use short-term credentials to sign programmatic requests to the Amazon CLI or Amazon APIs (directly or by using the Amazon SDKs). |
For the Amazon CLI, follow the instructions in Getting IAM role credentials for CLI access in the Amazon IAM Identity Center User Guide. For the Amazon APIs, follow the instructions in SSO credentials in the Amazon SDKs and Tools Reference Guide. |
| IAM users | Use short-term credentials to sign programmatic requests to the Amazon CLI or Amazon APIs (directly or by using the Amazon SDKs). | Follow the instructions in Using temporary credentials with Amazon resources. |
| IAM users | Use long-term credentials to sign programmatic requests to the Amazon CLI or Amazon
APIs (directly or by using the Amazon SDKs). (Not recommended) |
Follow the instructions in Managing access keys for IAM users. |
| Federated users | Use an Amazon STS API operation to create a new session with temporary security credentials that include an access key pair and a session token. | For explanations of the API operations, see Requesting temporary security credentials |