Get credentials for local development

Use short-term credentials from a sign-in, never pasted access keys, and prove the identity before the first real call. AWS's best practices require temporary credentials for human users and recommend IAM Identity Center for managing that access.

1. Pick the path

Ask your human how they sign in to the AWS console today.

They sign in through	Use	Minimum CLI
An AWS access portal or company identity provider (Identity Center)	aws configure sso	any v2; PKCE sign-in from 2.22.0
The AWS console directly, as an IAM user, the root user, or a federated IAM identity	aws login	2.32.0
Neither works (a tool that supports neither)	Access keys for an IAM user, as a last resort	any

Check the version with aws --version. aws login does not cover Identity Center users; they use the first path.

2a. IAM Identity Center

aws configure sso

Answer the prompts: a session name, the start URL (or issuer URL), the Region that hosts Identity Center, and the scope sso:account:access. Your human approves the sign-in in a browser, then picks the account and role. On a machine without a browser, add --use-device-code. The result in ~/.aws/config:

[profile <name>]
sso_session = <session>
sso_account_id = <account-id>
sso_role_name = <role>
region = <default region>

[sso-session <session>]
sso_start_url = <start URL>
sso_region = <Identity Center region>
sso_registration_scopes = sso:account:access

Each day, or when the sign-in expires: aws sso login --profile <name>. Role credentials renew automatically while that sign-in is valid. Sign out with aws sso logout.

2b. aws login (console credentials)

Non-root identities need the AWS managed policy SignInLocalDevelopmentAccess attached (or an equivalent); the root user needs nothing extra.

aws login --profile <name>

The CLI asks for a Region if the profile has none, opens a browser where your human picks the console session to use, and writes login_session = <identity ARN> to the profile. Credentials last 15 minutes and refresh automatically for up to 12 hours (or the principal's session duration, if shorter); then run aws login again. Without a browser on this machine: aws login --remote, open the printed URL elsewhere, paste back the code. Sign out with aws logout --profile <name>, or aws logout --all.

For older tools that do not understand console credentials, the CLI can serve them through a credential_process profile running aws configure export-credentials --profile <name> --format process.

2c. Access keys (last resort)

Only when neither sign-in path works. Store them in a named profile in ~/.aws/credentials, never in code or committed files, and plan to replace them: long-term keys are what the best practices tell you to avoid.

3. Use the profile

CLI: --profile <name> on each command.

Node.js (AWS SDK for JavaScript v3): the default provider chain already reads SSO and login profiles. To be explicit about which profile your code uses:

import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
import { fromIni } from "@aws-sdk/credential-providers";

const sts = new STSClient({ region: "<region>", credentials: fromIni({ profile: "<name>" }) });
console.log(await sts.send(new GetCallerIdentityCommand({})));

The SDK login provider needs SDK for JavaScript 3.x (not 2.x). Other SDKs: check the support table in the SDKs and Tools reference before assuming they work with aws login.

4. Prove the identity

aws sts get-caller-identity --profile <name> --debug

Confirm the account ID and role or user in the ARN are the ones your human intended, and that the debug output names the source you just set up. If it names environment variables or a different profile, an earlier source in the chain is winning: reference/sts/credential-sources.md. Errors (ExpiredToken, The provided token has expired, InvalidClientTokenId): reference/sts/errors.md.