Authentication and access using Amazon SDKs and tools
When you develop an Amazon SDK application or use Amazon tools to use Amazon Web Services services, you must establish how your code or tool authenticates with Amazon. You can configure programmatic access to Amazon resources in different ways, depending on the environment the code runs in and the Amazon access available to you.
The options below are a part of the credential
provider chain. This means that by configuring your shared Amazon config and credentials files accordingly, your
Amazon SDK or tool will automatically discover and use that method of authentication.
Choose a method to authenticate your application code
Choose a method to authenticate the calls made to Amazon by your application.
If your code runs on Amazon, credentials can be made automatically available to your application. For example, if your application is hosted on Amazon Elastic Compute Cloud, and there is an IAM role associated with that resource, the credentials are automatically made available to your application. Likewise, if you use Amazon ECS or Amazon EKS containers, the credentials set for the IAM role can be automatically obtained by the code running inside the container through the SDK's credential provider chain.
Using IAM roles to authenticate applications deployed to Amazon EC2 – Use IAM roles to securely run your application on an Amazon EC2 instance.
Lambda creates an execution role with minimal permissions when you create a Lambda function. The Amazon SDK or tool then automatically uses the IAM role attached to the Lambda at runtime, via the Lambda execution environment.
Use IAM Role for Task. You must create a task role and specify that role in your Amazon ECS task definition. The Amazon SDK or tool then automatically uses the IAM role assigned to the task at runtime, via the Amazon ECS metadata.
We recommend you use Amazon EKS Pod Identities.
Note: If you feel that IAM roles for service
accounts (IRSA) might better suit your unique needs, see Comparing EKS Pod Identity and IRSA
See the dedicated guide for your Amazon Web Services service. When you run code on Amazon, the SDK credential provider chain can automatically obtain and refresh credentials for you.
If you are creating mobile applications or client-based web applications that require access to Amazon, build your app so that it requests temporary Amazon security credentials dynamically by using web identity federation.
With web identity federation, you don't need to create custom sign-in code or manage your own user identities. Instead, app users can sign in using a well-known external identity provider (IdP), such as Login with Amazon, Facebook, Google, or any other OpenID Connect (OIDC)-compatible IdP. They can receive an authentication token, and then exchange that token for temporary security credentials in Amazon that map to an IAM role with permissions to use the resources in your Amazon Web Services account.
To learn how to configure this for your SDK or tool, see Assuming a role with web identity or OpenID Connect to authenticate Amazon SDKs and tools.
For mobile applications, consider using Amazon Cognito. Amazon Cognito acts as an identity broker and does much of the federation work for you. For more information, see Using Amazon Cognito for mobile apps in the IAM User Guide.
We recommend Using IAM Identity Center to authenticate Amazon SDK and tools.
As a security best practice, we recommend using Amazon Organizations with IAM Identity Center to manage access across all your Amazon Web Services accounts. You can create users in Amazon IAM Identity Center, use Microsoft Active Directory, use a SAML 2.0 identity provider (IdP), or individually federate your IdP to Amazon Web Services accounts. To check if your Region supports IAM Identity Center, see Amazon IAM Identity Center endpoints and quotas in the Amazon Web Services General Reference.
(Recommended) Create a least-privileged IAM user with permissions to
sts:AssumeRole into your target role. Then configure your profile to
assume a role using
a source_profile set up for that user.
You can also use temporary IAM credentials via environment variables or the
shared Amazon credentials file. See Using short-term credentials to authenticate Amazon SDKs and tools.
Note: In sandbox or learning environments only, you can consider Using long-term credentials to authenticate Amazon SDKs and tools.
Yes: See Using IAM Roles Anywhere to authenticate Amazon SDKs and tools. You can use IAM Roles Anywhere to obtain temporary security credentials in IAM for workloads such as servers, containers, and applications that run outside of Amazon. To use IAM Roles Anywhere, your workloads must use X.509 certificates.
Use Process credential provider to retrieve credentials
automatically at runtime. These systems might use a helper tool or plugin to
obtain the credentials, and might assume an IAM role behind the scenes using
sts:AssumeRole.
Use temporary credentials injected via Amazon Secrets Manager. For options to obtain short-lived access keys, see Request temporary security credentials in the IAM User Guide. For options on storing these temporary credentials, see Amazon access keys.
You can use these credentials to securely retrieve broader application permissions from Secrets Manager, where your production secrets or long-lived role-based credentials can be stored.
Use the documentation written by your third-party provider for best guidance on obtaining credentials.
Yes: Use environment variables and temporary Amazon STS credentials.
No: Use static access keys stored in encrypted secret manager (last resort).
Authentication methods
Authentication methods for code running within an Amazon environment
If your code runs on Amazon, credentials can be made automatically available to your application. For example, if your application is hosted on Amazon Elastic Compute Cloud, and there is an IAM role associated with that resource, the credentials are automatically made available to your application. Likewise, if you use Amazon ECS or Amazon EKS containers, the credentials set for the IAM role can be automatically obtained by the code running inside the container through the SDK's credential provider chain.
-
Using IAM roles to authenticate applications deployed to Amazon EC2 – Use IAM roles to securely run your application on an Amazon EC2 instance.
-
You can programmatically interact with Amazon using IAM Identity Center in the following ways:
-
Use Amazon CloudShell to run Amazon CLI commands from the console.
-
To try cloud-based collaboration space for software development teams, consider using Amazon CodeCatalyst.
-
Authentication through a web-based identity provider - Mobile or client-based web applications
If you are creating mobile applications or client-based web applications that require access to Amazon, build your app so that it requests temporary Amazon security credentials dynamically by using web identity federation.
With web identity federation, you don't need to create custom sign-in code or manage your own user identities. Instead, app users can sign in using a well-known external identity provider (IdP), such as Login with Amazon, Facebook, Google, or any other OpenID Connect (OIDC)-compatible IdP. They can receive an authentication token, and then exchange that token for temporary security credentials in Amazon that map to an IAM role with permissions to use the resources in your Amazon Web Services account.
To learn how to configure this for your SDK or tool, see Assuming a role with web identity or OpenID Connect to authenticate Amazon SDKs and tools.
For mobile applications, consider using Amazon Cognito. Amazon Cognito acts as an identity broker and does much of the federation work for you. For more information, see Using Amazon Cognito for mobile apps in the IAM User Guide.
Authentication methods for code running locally (not in Amazon)
-
Using IAM Identity Center to authenticate Amazon SDK and tools – As a security best practice, we recommend using Amazon Organizations with IAM Identity Center to manage access across all your Amazon Web Services accounts. You can create users in Amazon IAM Identity Center, use Microsoft Active Directory, use a SAML 2.0 identity provider (IdP), or individually federate your IdP to Amazon Web Services accounts. To check if your Region supports IAM Identity Center, see Amazon IAM Identity Center endpoints and quotas in the Amazon Web Services General Reference.
-
Using IAM Roles Anywhere to authenticate Amazon SDKs and tools – You can use IAM Roles Anywhere to obtain temporary security credentials in IAM for workloads such as servers, containers, and applications that run outside of Amazon. To use IAM Roles Anywhere, your workloads must use X.509 certificates.
-
Assuming a role with Amazon credentials to authenticate Amazon SDKs and tools – You can assume an IAM role to temporarily access Amazon resources that you might not have access to otherwise.
-
Using Amazon access keys to authenticate Amazon SDKs and tools – Other options that might be less convenient or might increase the security risk to your Amazon resources.
More information about access management
The IAM User Guide has the following information about securely controlling access to Amazon resources:
-
IAM Identities (users, user groups, and roles) – Understand the basics of identities in Amazon.
-
Security best practices in IAM – Security recommendations to follow when developing Amazon applications according to the shared-responsibility model
.
The Amazon Web Services General Reference has foundational basics on the following:
-
Understanding and getting your Amazon credentials – Access key options and management practices for both console and programmatic access.
IAM Identity Center trusted identity propagation (TIP) plugin to access Amazon Web Services services
-
Using the TIP plugin to access Amazon Web Services services – If you are creating an application for Amazon Q Business or other service that supports trusted identity propagation, and are using the Amazon SDK for Java or the Amazon SDK for JavaScript, you can use the TIP plugin for a streamlined authorization experience.
Amazon Builder ID
Your Amazon Builder ID complements any Amazon Web Services accounts you might already own or want to create. While an Amazon Web Services account acts as a container for Amazon resources you create and provides a security boundary for those resources, your Amazon Builder ID represents you as an individual. You can sign in with your Amazon Builder ID to access developer tools and services such as Amazon Q and Amazon CodeCatalyst.
-
Sign in with Amazon Builder ID in the Amazon Sign-In User Guide – Learn how to create and use an Amazon Builder ID and learn what the Builder ID provides.
-
CodeCatalyst concepts - Amazon Builder ID in the Amazon CodeCatalyst User Guide – Learn how CodeCatalyst uses an Amazon Builder ID.