How Do You Authenticate To AWS CLI Using Aws Login Without IAM Access Keys?

If you have worked with AWS CLI for a long time, you know the old pain. Create an access key. Save the secret key somewhere safe (mostly not safe). Paste in aws configure. Then pray that the key never leaks in some GitHub repo. Every learner who joins any AWS Course faces this same confusion in the beginning. But AWS finally gives a solution: CLI version 2.32.0 brings a new command called aws login.

It lets you sign in to the CLI the same way you sign in to the AWS Management Console. No access key ID. No secret key. Nothing to copy-paste. It opens your browser, you log in normally, and the CLI itself gets temporary credentials for you. In this blog, we go step by step through how this command works and how you can start using it today.

What Exactly is the aws login Command?

aws login is basically a shortcut. It connects your AWS Management Console sign-in session directly to your terminal. To understand why this matters, first look at how things worked earlier. To run any AWS CLI command like aws s3 ls or aws ec2 describe-instances, you needed a long-term access key and secret key pair. These get stored in ~the /.aws/credentials file. The problem with this approach is that these keys don't expire on their own. So if by mistake they get pushed to a public repo or leaked in some .env file, an attacker can misuse your AWS account for a very long time.

That is exactly where AWS login changes things. Behind the scenes, CLI uses OAuth 2.0 Authorisation Code flow with PKCE (Proof Key for Code Exchange), the same secure protocol many modern apps use for login. Instead of a static key, you get temporary, auto-rotating credentials. These refresh every 15 minutes and expire automatically after a maximum of 12 hours. As a result, even if these credentials got exposed somehow, the damage window stays very small compared to traditional access keys.

This method works for:

• Root user login
• IAM user login (username + password)
• Federated identity login (through your organisation's identity provider)

It does not replace IAM Identity Centre (SSO). If your company already uses Identity Centre, keep using AWS SSO login for that. AWS docs mention this clearly.

Prerequisites Before You Start

Before trying aws login, check the points below first:

1. Install the latest AWS CLI, the version should be 2.32.0 or above. An older version will not have this command at all.
2. You need access to sign in to the AWS Management Console as root user, IAM user, or through federation.
3. If you are an IAM user (not root), your identity needs permission for two IAM actions: signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token. The easiest way is attaching an AWS-managed policy called SignInLocalDevelopmentAccess to your IAM user, role or group. Root users don't need any extra permission for this.

How the Authentication Flow Actually Works?

Now that you know why AWS login exists, let's see what actually happens behind the scenes. The diagram shows what happens step by step when you type aws login in your terminal from local server startup till credentials landing on your disk. Many students who attend hands-on AWS Training in Chennai batches practice this exact flow in their very first CLI lab.

Figure 1: How aws login moves you from terminal to browser to temporary credentials, using OAuth 2.0 PKCE

In short, the whole thing happens in a few quick hops. First, the CLI starts a small local HTTP server on 127.0.0.1 at a random port. Then it opens your default browser and redirects to the AWS Sign-In endpoint. Note this is a different endpoint than the IAM Identity Centre OIDC endpoint used by aws sso login. Once you complete login there, the browser sends back the authorisation code to that local server. After that, the CLI exchanges this code for a temporary token. Finally, it saves a profile in your ~/.aws/config. The important part here this profile doesn't contain any access key, only a reference to the temporary session.

Scenario 1: Using Root or IAM User Credentials

This is the most common case for an individual developer or learner doing self-practice, just needing quick CLI access for daily labs.

Steps are like this:

Step 1: Open a terminal and run:

Step 2: If you have not set the default Region before, the CLI prompts you to enter one. Here is the exact prompt you will see:

Type your region, for example us-east-2 or ap-south-1, and press Enter. CLI remembers this for next time.

Step 3: CLI automatically opens your default browser.

Step 4: In the browser, one of two things happens:

• If you already logged in to AWS Management Console in that browser, you see a screen saying "Continue with an active session." Just click and go ahead.
• If you are not logged in yet, you land on the sign-in options page. Select "Continue with Root or IAM user" and enter your username and password like a normal console login.

Step 5: After successful login, the browser shows a success message. Go back to the terminal.

Step 6: Now verify everything is working by running:

aws sts get-caller-identity

If this command returns your account ID, user ID and ARN, your CLI is authenticated and ready to use, without touching a single access key.

Scenario 2: Using Federated Sign-In

This scenario applies if your organisation uses an identity provider (like Okta, Azure AD, etc.) for federated login to AWS, and you assume an IAM role after login. This is also a common setup that trainers cover during any structured AWS Course in Pune where corporate federation topics come up.

Step 1: Complete steps 1 to 4 from Scenario 1 above. Run aws login, set region if asked, browser will open.

Step 2: In the browser:

• If you already have an active console session from federated login, the browser shows you an option to pick your active IAM role session. If multi-session support is enabled on your console, you can even choose between up to 5 active sessions.
• If you have not signed in, or want credentials for a different role, open a new browser tab. Log in through your organisation's identity provider as usual. Then come back to the AWS login tab and click the "Refresh" button. Your new session shows up under active sessions now.

Step 3: Select the correct session or role and return to the terminal. CLI completes the process and confirms you are logged in.

Working With Multiple Profiles

Many of us handle more than one AWS account: client account, personal sandbox, and separate training account for lab practice. aws login supports profile switching too:

aws login –profile <PROFILE_NAME>

And then run any command against that specific profile like this:

aws sts get-caller-identity –profile <PROFILE_NAME>

Here is a real example of what output looks like once you run it:

(base) user@machine:~$ aws sts get-caller-identity --profile my-dev-profile

{

    "UserId": "AROAXXXXXXXXXXXXXX:my-dev-profile",

    "Account": "123456789012",

    "Arn": "arn:aws:iam::123456789012:role/MyDevRole"

}

(base) user@machine:~$

Running the aws sts get-caller-identity command to verify the AWS identity

associated with the my-dev-profile profile.

You can also set a specific region while logging in:

aws login –region <REGION NAME>

Figure 2: Same-device login with multiple profiles vs. --remote login for a headless server

Log in from a Remote Server (No Browser Available)

Sometimes you SSH into an EC2 instance or remote dev box which don't have a browser installed. For this exact case, AWS gives the --remote flag:

aws login –remote

This will not try opening a browser on that remote machine. Instead, it prints a URL. You copy this URL and open it on your local device laptop, phone, anything with a browser. Once you log in there and approve, temporary credentials get delivered back to that remote CLI session. Very useful for people working on a cloud bastion host or Cloud9-type setup during their remote labs.

Ending the Session

When you're done for the day, or want to log out cleanly, simply run:

aws logout

This closes the active CLI session and removes temporary credentials associated with it.

Session Duration and Auto-Rotation

Whichever scenario you use root, IAM user or federated the temporary credential issued by aws login behaves like this:

• Auto-rotates every 15 minutes, handled automatically by AWS CLI, AWS SDKs, and AWS Tools for PowerShell (Invoke-AWSLogin command for PowerShell users)
• Stays valid up to the session duration configured for that IAM principal, with a maximum cap of 12 hours
• After session duration finishes, CLI simply asks you to log in again. No manual key rotation needed ever.

This is honestly the biggest win compared to the old static key method. Nobody actually rotates access keys manually regularly in real projects everyone knows this, but nobody does it. aws login basically fixes this bad habit by design.

What About Older SDKs That Don't Support This Directly?

If you write code using some older version of the AWS SDK that doesn't understand these new console credentials natively, don't worry. You can still use the credential_process provider setup with AWS CLI. This way, even an old SDK can consume the temporary credential delivered by aws login. You don't need to rewrite your whole application just to remove access keys. Even someone studying for AWS Certified AI Practitioner and building small ML demo apps on old SDK versions can adopt this without touching their existing codebase.

Controlling Access With IAM Policy (For Teams/Admins)

If you manage an AWS account for your team or students, note that the AWS login feature is controlled by exactly two IAM actions:

• signin: AuthorizeOAuth2Access
• signin: CreateOAuth2Token

Attach the SignInLocalDevelopmentAccess managed policy to allow your IAM users or roles to use this login method. If your organisation uses AWS Organisations and wants to block this feature on some member account, you can simply deny these two actions using Service Control Policy (SCP). These resource ARNs help you scope the policy tightly:

arn:aws:signin:region:account-id:oauth2/public-client/localhost

Use this ARN for same-device authentication with aws login.

arn:aws:signin:region:account-id:oauth2/public-client/remote

Use this ARN for cross-device authentication with aws login --remote.

You May Also Read:

Amazon Command Line Interface

How to Download Kiro

AWS Certification Cost

AWS Components

Why This Matters for Anyone Learning Cloud Today?

Honestly, for beginners, the biggest confusion has always been around access key management: where to store it, how to not leak it, when to rotate it. With AWS Login, this whole headache basically disappears for local development use cases. You login same way you always log in to the console, and the CLI handles the rest silently in the background, rotating credentials every 15 minutes without you even noticing. This is exactly why most structured Amazon Web Services Certification Training programs are now updating their CLI modules to cover this method from day one.

This is not made for CI/CD pipeline or unattended automation. It is fundamentally an interactive method a browser is required, even in --remote mode. Long-term automation still needs another approach like IAM roles or Identity Centre. But for local coding, testing, or lab practice, this is clearly a better and safer default going forward.

Related Courses:

Cloud Computing Training

Google Cloud Course

AWS DevOps Course

Conclusion

AWS login is one of those quiet but very meaningful updates from AWS. It doesn't add a new feature to build something big, but it quietly closes a security gap that existed since the AWS CLI started the dependency on long-term static access keys. Static access keys are slowly becoming an old way of doing things. Industry moving toward exactly this kind of short-lived, auto-rotating credential model. If you're doing hands-on practice or just starting your cloud journey, learning this command early will save you a lot of trouble later.