DEV Community

Cover image for aws login: What AWS CLI's New Console-Credential Command Can (and Can't) Do
Yuuki Yamashita
Yuuki Yamashita

Posted on

aws login: What AWS CLI's New Console-Credential Command Can (and Can't) Do

#aws #devops #security #cli

Verified against AWS CLI 2.32.6 and the official AWS documentation / AWS Security Blog post as of July 2026. Where I couldn't confirm something against a primary source, I say so explicitly instead of guessing.

TL;DR

  • aws login (AWS CLI ≥ 2.32.0, announced 2025-11-19) lets you reuse your Management Console sign-in — root, IAM user, or IAM federation — to get short-lived CLI/SDK credentials via a browser-based OAuth 2.0 + PKCE flow.
  • It solves a real, common problem: long-lived access keys sitting in ~/.aws/credentials on developer laptops.
  • It is not a replacement for IAM Identity Center (SSO). If your org already uses Identity Center, keep using aws sso login — the docs explicitly route you there.
  • It is fundamentally interactive (browser required, even with --remote), so it doesn't fit unattended CI/CD.
  • Session length is capped at 12 hours regardless of what you want.

Why this matters

Ask any AWS developer where their long-term access keys live and the honest answer is usually "in a file I should rotate more often." aws configure with a static access key + secret is still the default onboarding flow at a lot of shops, and static keys are exactly the kind of credential that ends up in a leaked .env file or a public GitHub repo.

aws login, shipped in AWS CLI 2.32.0, is AWS's answer for the local development slice of this problem: instead of minting an access key, you authenticate the same way you already do for the Console — browser, MFA, federation — and the CLI turns that into temporary, auto-rotating credentials.

What aws login actually is

Confirmed locally — this environment has AWS CLI 2.32.6 installed, so the command exists and matches the docs:

$ aws --version
aws-cli/2.32.6 Python/3.13.9 Darwin/27.0.0 source/arm64

$ aws login help
NAME
     login -

DESCRIPTION
     Login for local development using AWS Management Console credentials.
     Each time the login command is called, the CLI will acquire temporary
     credentials and a refresh token that correspond to your selected console
     session. The CLI will refresh the temporary credentials automatically as
     long as the refresh token is valid.
...
Enter fullscreen mode Exit fullscreen mode

Under the hood it's an OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange), which protects against authorization-code interception. Two new CloudTrail events show up when it's used: AuthorizeOAuth2Access and CreateOAuth2Token.

Prerequisites

  • AWS CLI 2.32.0 or later.
  • Ability to sign in to the Console as root, an IAM user, or a federated identity. If you use IAM Identity Center, this command is not for you — the official docs point you to aws sso login instead.
  • The IAM identity needs the SignInLocalDevelopmentAccess managed policy attached (root needs no extra permissions).

The flow

  1. aws login (optionally --profile my-dev-profile).
  2. If no region is configured, the CLI prompts for one.
  3. The CLI opens your default browser to a signin.<region>.amazonaws.com/authorize URL.
  4. You pick which active console session to use, or sign in fresh (including MFA if required).
  5. The CLI receives the token via a local callback server, caches it, and prints a confirmation.

The result is a profile in ~/.aws/config that looks like this — note there's no access key anywhere:

[default]
login_session = arn:aws:iam::0123456789012:user/username
region = us-east-1
Enter fullscreen mode Exit fullscreen mode

What it can do

Reuse Console credentials for CLI/SDK access, across identity types. Root, IAM user, or federated identity all work the same way — this is notable because it gives root users a supported way to get programmatic access without ever creating a root access key, which AWS has been trying to get people away from for years.

Auto-rotate short-lived credentials. The CLI refreshes the underlying temporary credentials every 15 minutes automatically. The overall session lasts as long as the IAM principal's configured session duration, up to a hard cap of 12 hours, after which you run aws login again.

Handle browser-less remote hosts. aws login --remote disables the local callback server and instead prints a URL to open on a different device with a browser, then prompts you to paste back the authorization code — useful for SSH sessions onto a devbox.

Manage multiple accounts/roles via profiles.

$ aws login --profile my-dev-profile
$ aws sts get-caller-identity --profile my-dev-profile
Enter fullscreen mode Exit fullscreen mode

Switching what a profile points to is explicit — the CLI asks for confirmation before overwriting an existing profile's session.

Bridge to tools that don't understand login_session yet. Older SDKs or third-party tools that only understand credential_process can still consume aws login credentials indirectly:

[profile signin]
login_session = arn:aws:iam::0123456789012:user/username
region = us-east-1

[profile process]
credential_process = aws configure export-credentials --profile signin --format process
region = us-east-1
Enter fullscreen mode Exit fullscreen mode

Give admins fine-grained control over same-device vs. cross-device auth. Two distinct resource ARNs let you scope IAM/SCP policy separately for local (aws login) and remote (aws login --remote) flows:

arn:aws:signin:{{region}}:{{account-id}}:oauth2/public-client/localhost
arn:aws:signin:{{region}}:{{account-id}}:oauth2/public-client/remote
Enter fullscreen mode Exit fullscreen mode

Get audited. AuthorizeOAuth2Access and CreateOAuth2Token land in CloudTrail, so security teams can see when console-credential logins happen, from where, and for which identity — the same visibility you'd expect from any other authentication event.

Sign out cleanly. aws logout deletes cached credentials for a profile (or --all for every profile using login credentials). Credentials live in ~/.aws/login/cache (or AWS_LOGIN_CACHE_DIRECTORY if you override it).

What it can't do

It is not IAM Identity Center, and it doesn't replace it. This is the single most important limitation to internalize. AWS's own docs say: if you use IAM Identity Center, go use aws sso login instead. aws login is specifically for the root / IAM user / IAM-federation case. If your org already centralizes access through Identity Center, aws login isn't the tool that changes your workflow.

aws configure (static keys) aws sso login (IAM Identity Center) aws login (console credentials)
Credential lifetime Long-term, until manually rotated Short-term Short-term, auto-rotated every 15 min
Requires browser No Yes Yes (or --remote with manual code paste)
Works for IAM users with access keys Identity Center users Root, IAM users, IAM federation
Centralized org access management No Yes No
Fits unattended automation Yes (with the usual risk tradeoffs) No No
Audit trail Access key usage only SSO sign-in events AuthorizeOAuth2Access, CreateOAuth2Token in CloudTrail

Session length is hard-capped at 12 hours. No flag extends it. Once the IAM principal's session duration (max 12h) elapses, you re-run aws login. For a long-running local process that needs to survive past that window unattended, this is a real constraint.

It's not built for CI/CD or any unattended automation. Every documented flow — including --remote — ends with a human either clicking through a browser or pasting an authorization code. There's no headless mode. This isn't stated as an explicit "not supported" bullet in AWS's docs, but it follows directly from the mechanism: OAuth 2.0 authorization-code-with-PKCE inherently requires a human in the loop at least once per session. For pipelines, the existing answer is still OIDC federation, instance profiles, or task roles — aws login doesn't change that.

Mixed credential sources cause confusing errors. If a profile already has static credentials sitting in ~/.aws/credentials, those take precedence over login_session, and you'll get ExpiredToken or AccessDeniedException even though aws login "succeeded." AWS's own troubleshooting doc calls this out explicitly — aws configure list shows a TYPE column, and if it says anything other than login, that's your problem. You have to manually clear the conflicting static credentials.

Firewalls can break the local flow. The default flow opens a local callback server to catch the OAuth redirect; if a firewall blocks that port, the login hangs or fails. The documented workaround is --remote, not a fix to the underlying flow.

GovCloud / China regions — unconfirmed as an aws login-specific limitation. I looked for a primary source stating aws login explicitly doesn't work in AWS GovCloud (US) or the China regions and didn't find one. What I can confirm is that GovCloud and China operate in entirely separate partitions (aws-us-gov, aws-cn) with separate accounts and credentials from a standard commercial account — so a commercial-account console session wouldn't authenticate you into those partitions regardless of which CLI credential method you use. If you operate in those partitions, verify this against current AWS docs for your account type rather than taking my word for it.

Practical verdict

If your team is still handing out static IAM access keys for local development and hasn't adopted IAM Identity Center, aws login is a meaningful upgrade with very little setup cost — attach SignInLocalDevelopmentAccess, run aws login, done. It also quietly closes a bad pattern: root users doing programmatic work over long-term root access keys.

If your org already runs IAM Identity Center, this command isn't for you — you already have short-lived credentials and centralized access management, and aws login doesn't add anything there.

And for anything unattended — CI/CD, scheduled jobs, Lambda, EC2 — nothing changes. aws login is a local, interactive developer tool, not a service-to-service auth mechanism.

References

Top comments (0)