AWS re:Invent 2025 - Easy cross-cloud authN : AWS outbound identity federation in action (SEC233)

🦄 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 - Easy cross-cloud authN : AWS outbound identity federation in action (SEC233)

In this video, Ram Maharajapuram and Vaishnavi Merugu introduce AWS's new feature that eliminates long-term credentials by enabling workloads to connect to external services using JSON Web Tokens (JWTs). A live demo shows an EC2 instance federating to Azure using the GetWebIdentityToken API without managing passwords or access keys. The token includes standard OIDC claims and custom AWS claims like account ID, principal tags, and compute context. The feature uses account-specific issuer URLs for tenant isolation and supports ES384 and RS256 signing algorithms. Three new condition keys control access: IdentityTokenAudience, DurationSeconds, and SigningAlgorithm. Available at no additional cost across all AWS regions, this solution enhances security by replacing two-thirds of credential-related incidents while reducing operational complexity through native integration with cloud providers like Azure, GCP, and SaaS platforms like Databricks and Snowflake.

; 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 Outbound Web Identity Federation: A Live Demo of Passwordless Authentication

Oh, it's one o'clock. Hey everyone, I hope you're having a great time at re:Invent. So before we get started, quick show of hands, how many of you hate managing passwords, access keys, and long-term credentials in general? All right, that's pretty much everybody in the audience here. So we have some great news for you, a new launch.

My name is Ram Maharajapuram. I am a Senior Software Development Manager and Head of Engineering for Security Token Service, and with me here today is Vaishnavi Merugu, a Senior Product Manager on the team. And we're here to talk to you about our latest launch that makes it easy for you to connect your workloads to external services.

Oftentimes builders have to trade off between security and ease of use, and with this new solution you no longer have to face that dilemma. You now have a native way to exchange your AWS credentials and use them to connect to any third-party services. So this could be other cloud service providers, it could be on-premises workloads, it could be SaaS providers, so cloud service providers like Azure, GCP, SaaS providers such as Databricks, Snowflake. And you could do this natively using the AWS credentials that are already available to you for any role, any IAM user.

These credentials more often are actually delivered natively to the compute that you're using, AWS Lambda, EC2, Amazon EKS, you name it. We have a secure way for you to connect those workloads to these external services, and we do this using standards-aligned JSON Web Tokens, or JWTs for short. And with this you no longer have to use complex workarounds, and you certainly do not have to manage any long-term credentials.

So I'm actually going to do a quick live demo of this feature. What I'm going to be doing is I'm going to be connecting my EC2 instance to Azure and make calls to Azure APIs without ever having to create an Azure access key like a long-term credential or setting up a password. So what I have here is an EC2 instance. So you can see here that it is live, and I'm going to kick this off by running a script that I've prepared for you.

We're going to go through seven steps. The first of these is to basically just check what credentials I have. I ran the command AWS STS get-caller-identity. It's basically the "who am I" command that we have on AWS. And what you see here is I have credentials that belong to an EC2 instance role. So when you spin up an EC2 instance, we actually have short-term credentials, session tokens that are delivered for you. These are valid only for a few hours, and these credentials can be scoped down however you want, and I'm going to be using these credentials for federating out into Azure.

So in order for you to use this feature, you would first have to go ahead and enable the outbound identity federation feature. I already have this feature enabled on my account, so I'm just using the get version of this command, AWS IAM get-outbound-web-identity-federation-info. And what I get here is a JSON with two elements. The first element is an issuer identifier. So when you enable this feature, we create a set of asymmetric keys for your account. We also create a unique identifier for your account, and we host the public keys corresponding to it on this URL, and your relying party can then call this URL and get those keys. We'll get to that in a bit more detail later. And it also says that JWT vending enabled is true. That's exciting.

So let's actually go look at what that JWT actually looks like. So I now ran the command AWS STS GetWebIdentityToken.

The response that I got has two elements in it: a web identity token and an expiration timestamp. I truncated the token just so that it's easier for us to talk through it, but essentially this token has three parts to it. There is a header that's shown in green color here, there is a payload, and there is a signature associated with that token. There's also an expiration timestamp. The expiration here by default is five minutes. You could also extend that beyond five minutes up to an hour if you would like to do so by just passing an API parameter to this. You can also see that I passed an audience parameter into this call because we're going to be using this token to exchange with Azure. We also have a signing algorithm here. I chose RS256, but there are other options available for you as well.

Let's actually look into what is inside this token. All I did is I did a base64 decode on this token and ran it through a JSON parser. What you see here is a subject, and the subject here is basically the same as my EC2 instance role that we used in order to get this JWT. You can also see a bunch of other standard claims including the issuer that we talked about earlier, an expiration timestamp, an issued at timestamp, and so on. There is also a bunch of interesting credential-specific or workload-specific claims that we have namespaced to sts.amazonaws.com. This includes things like properties of your EC2 instance, information about your ARN if you have one, and things like the tags that you actually have on the role. If you have session tags and so on, those will also appear here. There's an interesting off-label use case here. You could use this feature to introspect your authorization context and get additional information on what tags you have and so on if you are troubleshooting.

Here's the moment of truth. What I did is I took that credential and I exchanged this to an Azure access token. In order to do that, I posted that token to the Azure token exchange endpoint. I passed the grant type as client credentials and said that the assertion type is JWT bearer, and I got essentially a token back. Now what I can do is use these tokens to call other Azure APIs, and what you see here is that I'm using this token to call the Graph API for an application that I've already set up. The API that I'm calling is Federated Identity Credentials. Interestingly, this is all the setup that I had to do on Azure in order to connect my application. I gave Azure the subject, which is the EC2 instance role. I gave Azure the unique URL for my account that we talked about earlier and the audience, and I created a federated credential using that, and that was enough for me to securely connect to Azure.

Now we spoke about those issuer URLs, so you may be wondering how did Azure actually validate the token that we gave to it. What we publish is a couple of well-known endpoints on that issuer URL. The first is called the well-known OpenID Configuration endpoint. This basically tells you what kind of claims we support, what kind of token algorithms we support, and a URL for the JSON Web Key Set. This is where our public keys are actually hosted. What you see here is I'm also curling the JSON Web Key document, and you see here that the public keys corresponding to the RSA algorithm type and an ECDSA algorithm type are available. So what Azure did behind the scenes is they went to the configured endpoint and then figured out what the public keys were and used those to validate the token signature.

Now if you're using this for your own workloads, we've made it super easy for you. You can pick any library that understands and parses JSON Web Tokens, and those libraries would be able to natively do this for you. We have some example libraries on our documentation. And to tell you more about the claims and additional fine-grained controls that we have, I'd invite Vaishnavi on stage.

Key Benefits and Understanding JWT Claims in AWS Web Identity Tokens

Thank you, Ram. So now that we've all seen an exciting demo of this feature, let's talk about what are the primary benefits of using this feature. The first one's obvious, right? This is enhanced security because you're now eliminating long-term credentials from your environment. So, quick interesting fact, two-thirds of the cases that come to the customer incident response team are due to an initial access by an unintended actor using valid long-term credentials. So take advantage of this feature and replace your long-term credentials with short-lived JSON Web Tokens for secure access to external services.

The second one is reduced operational complexity. You no longer have to manage these long-term credentials or rotate them frequently. If you were using pre-signed URLs and complex authentication flows to integrate with these external services, you can replace all of that with a simple few lines of code, a simple API call to the GetWebIdentityToken API, and get a JWT for authentication with external services. Third is the interoperability. So this feature was designed to be interoperable with many of your external cloud service providers, SaaS providers, and even used for authentication between your own applications hosted on cloud or on premises.

Now let's actually do a quick recap of the claims that you just saw in the demo. So the claims can be broadly categorized into two. The first one is your standard OIDC claims. So these are again designed to be interoperable. We have the standard subject claim which identifies the role or the user or the IAM principal that's being federated to the external service. We have the audience of the token, we have the expiration time, a unique identifier for this JWT, and the issuer URL.

Then we have a set of custom claims that AWS puts in the token on your behalf. All of these claims are namespaced under sts.amazonaws.com, and this includes identity context, session context, compute context, and even your principal tags, the request tags that you can add to the token. Let's actually pay special attention to the issuer URL here. So when we were building this feature, we thought what would be a good way to deliver a secure by design experience for customers? And we decided to go with an issuer URL that's specific to your AWS account to guarantee tenant isolation.

So now let's look at the custom claims within the token. The AWS account ID is included in the token. This helps the downstream service validate that the token is coming from the account that you trust. We also include the source region, which is the AWS region from which the token generation request was made. If your AWS account is part of an organization, we include the organization ID and the OU path in the token as well.

Then we have principal tags. So if your IAM principal, like your role or your user has tags attached to them, those tags show up under the principal tags. And if your assumed role session has session tags attached to them, the session tags also show up in the principal tag section. Both of these can be used for fine-grained authorization in the downstream service.

Then we include some context that's particular to your compute. So in Ram's example you may have seen that there were some claims pertaining to the EC2 instance. So for example, if it was a Lambda function that's actually federating its identity, you would see Lambda function specific claims in the token. And if the identity originally federated from an external provider, we also include the federated provider information. And there are a lot of other claims that are very specific to your session context and your compute context. You can go through the full list on our documentation.

Access Control, Condition Keys, and Best Practices for Secure Token Management

Now, if you wanted to add your own claims to the token, you could do that by passing the tag parameter to the API call and specify the key value pairs. All of these would show up under the request tag section in the token, and you can use these again for fine-grained authorization in the external service. Now, let's talk about how you can control access to this feature for your IAM principals. So the permission to keep in mind here is the sts:GetWebIdentityToken permission.

Any IAM principal who has this permission in their policies will be able to generate JSON Web Tokens for authentication with external services. You can use this permission in any and all relevant policy types, including your SCPs, RCPs, identity-based policies, and VPCE policies.

We're also introducing three new condition keys as part of this feature. The first one is the IdentityTokenAudience condition key. Using this condition key, you can restrict the list of audiences and ensure that your IAM principals only generate tokens for these audiences. If they try to generate a token for any other audience, the request will fail.

We also have the sts:DurationSeconds condition key, which can be used to enforce maximum token lifetimes. Tokens are valid for five minutes by default, but the token lifetime can range anywhere between 60 seconds to one hour. You can set maximum token lifetimes that suit your operational needs and your security requirements.

Finally, we have the sts:SigningAlgorithm condition key. We currently support two signing algorithms: ES384 and RS256. You can use this condition key to specify the signing algorithm to be used to sign the token.

Now, let's talk about a few best practices. Before that, let me tell you that this feature is available in all AWS commercial regions, GovCloud regions, and China regions at launch, and this feature is available at no additional cost to customers. As I mentioned before, the primary goal of building this feature is to eliminate long-term credentials from your environment. Please replace all your API keys and passwords with short-term, short-lived JWTs and make them as short as possible to prevent unintended access.

Look at the authorization context in your token after you validate the signature, so ensure that the token is actually issued by AWS and it's valid before you look at the authorization context. Also look at the custom claims in the token that AWS populates whenever possible to do more fine-grained access control in the downstream service. Make sure you don't log these tokens. You can request a fresh token anytime you need, and also make sure you send these requests over TLS.

You can refer to these QR codes for more resources. The first one is our blog post, which talks about a walkthrough of how to use this feature, and for an in-depth guide, you can look at our documentation as well. Thank you so much for joining us today, and please do take the session survey once it pops up on the app. Thank you very much once again.

---

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