AWS Builder Center

Builder Center

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

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

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.

Yuuki Yamashita

Cloud Engineer

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:
Plain text
$ 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.
...
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 ).
  1. If no region is configured, the CLI prompts for one.
  1. The CLI opens your default browser to a  signin.<region>.amazonaws.com/authorize  URL.
  1. You pick which active console session to use, or sign in fresh (including MFA if required).
  1. 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:


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.
Plain text
$ aws login --profile my-dev-profile
$ aws sts get-caller-identity --profile my-dev-profile
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:
ini
[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
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:
Plain text
arn:aws:signin:{{region}}:{{account-id}}:oauth2/public-client/localhost
arn:aws:signin:{{region}}:{{account-id}}:oauth2/public-client/remote
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

# aws-iam-identity-center# oauth
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article