AWS re:Invent 2025 - Programmatically access AWS with your console credentials (SEC354)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Programmatically access AWS with your console credentials (SEC354)

In this video, Ram Maharajapuram and Khaled Sinno from AWS IAM introduce AWS login, a new feature that allows developers to use their AWS console credentials for programmatic access via CLI. The feature eliminates the need to create and manage long-term access keys, addressing security concerns as two-thirds of AWS Security Incident Response cases involve compromised long-term credentials. Using OAuth 2 authorization code flow with PKCE, AWS login generates short-lived tokens (15 minutes) that auto-refresh for up to 12 hours. Khaled demonstrates the setup process, including upgrading to AWS CLI version 2.32.9+, logging in with root, creating an IAM user with MFA, and switching to least-privilege access. The feature works across 11 AWS SDKs and supports headless environments through remote authentication. Required permissions include SignInAuthorizeOAuth2Access and SignInCreateOAuth2Token, available via the SignInLocalDevelopmentAccess managed policy.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introducing AWS Login: Bridging Console and Programmatic Access

All right. So before we get started, I have a couple of quick questions for you all. Let's rewind back to the time when you created your first AWS account. How many in here actually use separate methods for programmatic access and logging into your AWS console? There's a few. Okay, there's definitely some friction and fragmentation here. How did you go about creating and managing those programmatic access keys to AWS from your local development environment? Okay. Did you find that process simple? Okay. Got it.

So you're all at the right place to learn about how we can make the process secure and simple. Oftentimes, developers kind of go through this trade-off where secure is not necessarily simple, and we're here to talk to you about our latest launch: programmatically access AWS with your console credentials. My name is Ram Maharajapuram. I'm a Senior Manager, Software Development in AWS IAM, and with me here today is Khaled Sinno. He is a Principal Engineer at AWS IAM.

So we talked to a lot of customers like you all, and the constant themes that we were essentially hearing is very similar to the initial questions that we talked about. So we asked ourselves, what can we do to make the complexity go away? What can we do to make the secure path the easy path from the very beginning for customers new to AWS? And how can we help existing customers such as yourselves who use long-term credentials for programmatic access move to short-term credentials so that you align with security best practices?

So what did we build? And when we started asking these questions, it basically led us to build AWS login. So when you type AWS login on your favorite terminal application, you use the same credentials that you use to log in to the AWS console for programmatic access from the command line. So you don't necessarily need to create a new identity, no more access keys for local development, and so on.

So what happens when you do this? The very first time you do this, we actually ask you which AWS region you want to use. Clearly we have 38 of them at this point in time. The CLI will then open up your default browser, and if you're already signed into the AWS Management Console, we remember that and we then generate a temporary security credential based off of that and securely deliver that to your terminal application. And if you're not logged in, then you would be able to authenticate at that point in time.

You would be able to use your multi-factor authentication. We support a broad array of MFA options for you, and we would then use the resulting session in order to bridge to the short-term credential, if you will. Now you may ask, hey, I do my development in a headless Linux VM. How do I pop open a browser at that point? We've got you covered. We actually have a remote option, so that way we will then take you through a cross-device authentication workflow and we'll deliver those credentials securely for you.

Security Architecture and Developer Benefits of Short-Term Credentials

So all of this begets the question, how is this secure? The most obvious one is that it eliminates the need for you to create, manage, and store long-term credentials. So an interesting fact is that roughly two-thirds of the cases handled by the AWS Security Incident Response team begins with unauthorized access that some third party got because of a long-term credential. So we would highly recommend that you switch to short-term credentials, but it's just not that. There is a little bit more under the hood here as well.

What we do here is we use OAuth 2 authorization code flow. So this uses something called PKCE, which is short for Proof Key for Code Exchange. This protects you against interception attacks.

We also make sure that these tokens are short-lived, but sorry for the slider advancing there. We also take care of the tokens. Even though they are short-lived, we take care of refreshing them behind the scenes so that they can be valid for up to 12 hours. We also have some cryptographic mechanisms in there to make it harder to steal these credentials from one device to another.

It's also a very easy getting started experience. All you have to do is download the most recent AWS CLI, type AWS login, and off you go. It also helps you with improved productivity. We've been talking a lot about the CLI here, but it is not just about CLI access. These credentials are usable from any of the 11 AWS SDKs and the various programming languages that we support. Say you're running Kiro and you're creating a Python script that is used to access several AWS services. That Python SDK would also be able to use the same credentials in order to authenticate to those services, so you don't necessarily have to create any new credentials at that point.

When you're done building your scripts, this gives you an easy path to essentially deploy these to AWS, whether it is into an AWS EC2 instance using instance roles or to a Lambda using execution roles. All of those also use short-term credentials, and it gives you that very seamless transition, if you will. Khaled here is actually brave enough to go do a live demo of how this works for you all. So let's all pray to the demo gods and make sure that the Wi-Fi remains stable.

Live Demonstration: From Root Access to IAM User Best Practices

Thank you, Ram. Hi everyone. The best way to talk about this feature is to show you the feature, so we're going to demo this feature. Let me switch to the demo. All right, so to start using the AWS login CLI, you want to make sure first that you upgrade your CLI to have this feature. If you're using Mac, for example, like me, you could do brew upgrade AWS CLI. What you want is a version above 2.32.9. If you have that version, then you're going to be able to use the AWS login CLI.

Now if you haven't installed the AWS CLI, you can go to this documentation page. It shows you how to install it for Windows, for Linux, for Mac. All right, so once you upgrade your CLI, you can do AWS login, and what AWS login is going to do is open up the browser and show you what your logged-in sessions are. Let's take the scenario where you just created an AWS account. By default, you're automatically logged in as root and your session is live. I go to my terminal, I do AWS login as you saw here, and then it lists automatically for me the sessions available in my browser. I can press on the session, and you can see here automatically it updated my profile to use this console login.

If I do now AWS STS get caller identity, you can see that the account that it mentioned is this one that we were just logged into, and it's root. Now, let's imagine that you created your account and then you went for a coffee, a very long coffee, more than 12 hours. Your credentials expired, right? So let's simulate that. We're going to go here first. We're going to do console. We're going to log out from our session to simulate it, and we're going to do AWS logout. Let's start from scratch. Let's do AWS login.

It's going to pop up the browser again, and this time there's nothing to show you to sign into, right? So you're going to have to sign in with a root or with an IAM user. I'll click refresh. There's nothing here available. We're going to click on continue with the root and IAM user. All right, in this case, we're going to log in with root because this is what we have after we created an account, right?

We're going to choose our accounts. I'm going to click next. We're going to type in, hopefully, the right code. And the password. Once you click sign in, it's going to ask you for an MFA code because every root access requires an MFA code, and so now I have to put in my MFA code and sign in. You can see here it updated the profile to this one.

Now if I do aws sts get-caller-identity, you can see that I'm logged in with the root for that account. Great. Now that you've established access, you should move away from root because working with root is not the best practice. You should always work with least privilege. So what we're going to do now is we're going to go to our console since we're logged in, and we're going to create an IAM user specifically for our AWS login CLI.

So we're going to go to IAM and we're going to create an IAM user here. Users, create user, and we're going to call it, let's say, demo-user. All right, we're going to put in a password that I can remember. Click next, and we're going to attach a policy, and in this case maybe we're going to choose an administrator access just for simplicity here. Next, and then create the user.

All right, next, as a best practice, I suggest you add MFA for your user to make it secure, and so we're going to go to enable MFA. In this case, I'm going to just put the passkey because that's the simplest way for me to do it, and I'm going to call it my work MacBook. Next, I say continue. I'm going to use my thumbprint, and it's been created.

All right, let's go back to our CLI. We're going to log out and clear, and we're going to do aws login. Right, it still remembers my root user. I don't want to use my root user, so we're going to say sign into a new session in this case. In this case, I'm going to log in with this one, with this account, demo-user, and the password that I'm not going to share with you. Okay, they asked me for my MFA or my passkey.

I logged in, and now it asks me, do you want to override your stored credentials that were for root with the demo-user? I'm going to say yes. Let's verify that it's now using those credentials. So if I do get-caller-identity, what I expect is the demo-user, and that's what you see here. Right, and now it's a safe way for you to use the AWS login CLI without having static credentials stored anywhere on your boxes. These are 15-minute credentials automatically refreshed behind the scenes that auto-expire after 12 hours, and that's the safe way to use to access your CLI going forward.

Woohoo, thanks, thanks, Khaled, for the demo. So can you actually walk us through, so you used admin access for your IAM user, but obviously, like in many cases, we may not want to use admin access. So how can I use fine-grained access for this feature? So first of all, to be able to use this feature, the login, you're going to need additional permissions. Okay, so for all of your IAM users, you're going to need a couple more permissions that I think we're going to show on the PowerPoint, hopefully.

Is it showing? Yep, okay, so we're going to need two additional permissions: the SignInAuthorizeOAuth2Access and the SignInCreateOAuth2Token. If you have those permissions, then you can use the AWS login CLI and get an access token that is 15 minutes long. Right, now if you don't want to add those permissions on every single principal of yours manually, there's a managed policy for that, and it's called SignInLocalDevelopmentAccess. Just attach that one to all of your principals, and they can start using your AWS login CLI.

Got it. Okay, so does this mean that using root is cool again? That seems like a trick question.

You should always operate in a least privileged manner. You can see here that I started with the root and I quickly switched away to something else, and I put administrator access. In this case, that's probably not a best practice. You should probably put read-only access or something more restricted. Always operate in a least privileged manner. Walk away, stay away from root unless you absolutely need it. This is why we launched a feature for organizations last year that allows you to remove root from all of the member accounts of an organization so that you can only assume a root temporarily from the management account when you need it. Always operate in least privilege. That's the guidance.

Got it. And what are your recommendations for IAM users? Historically, we would say stay away from IAM users because they have long-term access keys, but this is changing now. As long as you don't create static credentials that are long-term access keys, these are perfectly fine. These are very short-term credentials, shorter than your normal session that automatically refresh under the hood. So this is a very good way, but I do recommend you always add an MFA. Since these are humans using those credentials, add an MFA.

All right, so that's pretty much it. As you've seen, we've actually tried to give you a secure and easy way for you to log in into AWS using your console credentials and use them for programmatic access from your local development. All you have to do is install the latest version of the AWS CLI, run AWS login, and then go build. Thank you all. Thank you.

So a couple of things. You'll get a survey question popping up on the AWS events app, so please fill out that survey. That's super helpful for us. And then we will hang out just outside the hall. If you have any questions, we're happy to take those questions as well. Just going to remove our mics and we can meet you here. Thank you. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.