Automating OIDC-Based Cross-Cloud Authentication in AWS

Table of contents

Introduction

This is a written and expanded version of my conference talk presented at the Commit Your Code 2025 conference. The recording of the session can be found online on YouTube.

Problem Description

Imagine you have an external application (let’s say a CI/CD system) that needs to interact with your AWS account. This could be for deploying applications, updating resources, or provisioning new infrastructure.

This CI/CD system should also be able run on autopilot, with minimal user input. It might kick off pipelines in the early morning hours based on a schedule, trigger a deployment when a PR is merged, or even run in the middle of the night to respond to an incident.

So, how do you ensure the system can authenticate to AWS to carry out these tasks?

IAM Users…

A quick and straightforward solution would be to create an IAM user for the CI/CD system, generate an Access Key ID and Secret Access Key. That’s one way to get the job done.

But here’s the catch: Access Key ID and Secret Access Key are essentially a static username/password combo. They’re long-lived credentials; meaning they don’t expire unless you manually rotate them, and they’re a major security risk if exposed.

In other words, if these credentials are ever leaked, your AWS environment is wide open to exploitation. And that’s not something you want, especially for a system running unattended.

There are several other issues with relying on Access Key IDs for AWS authentication:

• They go against AWS security best practices: AWS strongly recommends using temporary credentials (like those from IAM roles) instead of long-lived access keys.
• They often conflict with enterprise security policies: In large organizations, permanent credentials can violate internal compliance standards and raise red flags with security teams.
• They may breach regulatory compliance: For environments governed by regulations like HIPAA, the use of long-lived credentials can directly contradict security requirements and expose the organization to compliance risks.

The Quick Fix: Rotate Credentials…

Many organizations go down the road of building Frankenstein-like scripts to rotate Access Key ID/Secret Access Keys regularly. While this can help mitigate the risk of exposed credentials, it’s more of a band-aid solution than a sustainable fix.

So, what’s the better way to handle this situation?

OIDC to the Rescue

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It enables applications to verify users’ identities using tokens issued by an external identity provider (IdP). These tokens contain valuable information, such as claims (user attributes) and scopes (permissions), allowing for more contextual and secure access control.

One of the key advantages of OIDC is its support for short-lived, dynamically scoped tokens. Unlike long-lived AWS IAM access keys, OIDC tokens are designed to expire quickly and can be fine-tuned for specific permissions. This significantly reduces the risk of overly broad access and stale credentials, improving both security and manageability.

OIDC enables Single Sign-On (SSO), allowing users to authenticate once and access multiple applications without re-entering credentials. This is especially valuable in enterprise environments where centralized access control are critical. With OIDC, applications can offload authentication to trusted identity providers like Microsoft Entra ID (formerly Azure Active Directory), eliminating the need to manage separate AWS IAM credentials for every user.

Secure Federated Access using OIDC within AWS

AWS supports OIDC federated authentication through IAM OIDC Providers, which allow external identity providers to securely authenticate users and grant them access to AWS services. This approach is particularly beneficial in scenarios where users (e.g. external contractors, third-party apps) require temporary access to AWS resources but should not have long-term IAM user credentials.

By using IAM Web Identity Roles, AWS can issue temporary credentials to authenticated clients based on policies attached to the role. This eliminates the need for creating and managing dedicated IAM users, and it drastically reduces the risk of credential leakage.

Microsoft Entra ID as an OIDC Identity Provider

Microsoft Entra ID is a powerful, cloud-based identity platform that provides robust tools for user lifecycle management. These include user provisioning, deprovisioning, and access control. It is frequently used at large organizations for managing enterprise-scale identities.

Entra ID also supports advanced governance and security features such as Conditional Access policies, Multi-Factor Authentication (MFA), and rich auditing and reporting capabilities. It can federate access to AWS through both OIDC and SAML, enabling organizations to centralize identity and access management while maintaining strong security posture.

Furthermore, Entra ID supports the registration of external applications, allowing developers to configure OIDC clients for secure, standards-based authentication across environments.

Integrated Solution

1. To enable secure, federated access from external systems such as CI/CD pipelines, an external application is first registered in Microsoft Entra ID.
2. This application authenticates using an Azure service principal, which acts as its identity. Upon successful authentication, Entra ID issues an OIDC token to the application.
3. The application then uses this Entra ID-issued token to request temporary AWS credentials from AWS Security Token Service (STS). If the request is valid and the IAM Web Identity Role’s trust policy authorizes Entra ID as a trusted identity provider, AWS STS exchanges the Entra ID token for a temporary AWS token.
4. With these credentials, the external application can assume the IAM role and gain access to the AWS resources defined in that role’s permissions. The entire flow is done securely and without the need for long-term IAM credentials.

Manual Configuration

NOTE: Entra ID Application / Client ID is referred to as the Audience in AWS IAM.

Manual configuration of AWS IAM and Microsoft Entra ID integration consists of three steps:

1. Create Application Registration in Entra ID
2. Add Audience to AWS IAM OIDC Provider
3. Create AWS IAM Web Identity Role

Pre-requisite: AWS IAM OIDC Provider

In the AWS Management Console for IAM, create an IAM Identity Provider:

1. In the left navigation pane, select Identity providers and then choose Add an identity provider.
2. For Provider type, choose OpenID Connect.
3. For Provider URL, enter https://sts.windows.net/<Microsoft Entra Tenant ID>. Replace <Microsoft Entra Tenant ID> with your Tenant ID from Azure.
4. For the Audience field:

• If you’ve already registered an application in Entra ID (see steps below), use the application / client ID from the application registration.
• If you have not registered an application, enter any dummy value (e.g. dummy-value)

Entra ID Application Registration

1. In the Azure portal, select Microsoft Entra ID.
2. Select App registrations.
3. Select New registration.
4. Enter a name for your application and then select an option in Supported account types (in this example, we chose Accounts in this Organization directory only). Leave the other options as is. Then choose Register.

Once created, Entra ID will provide an Application / Client ID:

Add Audience to the AWS IAM OIDC Provider

Using the Application / Client ID value obtained from Entra ID, we add a new audience value to the Entra ID IAM OIDC provider:

1. In AWS IAM service, select the (already-configured) Entra ID OIDC Provider
2. In the Actions menu, select Add audience

AWS IAM Web Identity Role

Final step is to create a new AWS IAM Web Identity Role. We specify the Entra ID IAM OIDC Provider, and our application registration audience value:

Below shows the IAM trust policy that enables the integration from IAM Web Identity Role to the Entra ID application registration:

{
    "Effect": "Allow",
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Principal": {
        "Federated":
        "arn:aws:iam::<AWS Account>:oidc-provider/
        sts.windows.net/<Microsoft Entra Tenant ID>"
    },
    "Condition": {
        "StringEquals": {
            "sts.windows.net/<Microsoft Entra Tenant ID>:aud": [
                "<Audience>"
            ]
        }
    }
}

Issues with Manual Setup

Challenges of Manual Setup in Enterprise Environments

Manually configuring identity federation between AWS and Microsoft Entra ID can introduce several risks in enterprise settings.

Manual setup often leads to inconsistencies, especially when multiple individuals are involved. Each person may take a slightly different approach, resulting in misaligned configurations that can violate enterprise security policies and compliance requirements. In regulated industries, this lack of standardization can have serious consequences.

The process requires elevated access privileges across both AWS and Entra ID. Granting broad permissions for manual tasks increases the risk of accidental misconfigurations or, worse, exposure of sensitive resources—creating a significant security risk.

Another common hurdle is the depth of expertise required. Setting up a secure and reliable federation between these platforms demands a strong understanding of both AWS IAM and Entra ID’s identity and access management features. Many organizations struggle with this due to limited in-house expertise or competing priorities within their IT teams.

Finally, it’s important to recognize that manual configuration is inherently error-prone. A missed setting, incorrect permission, or misapplied policy can lead to hours of troubleshooting or a costly security gap.

For these reasons, automation and standardized tooling are strongly recommended when integrating identity providers in enterprise-scale cloud environments.

The Need for Automation at Scale

In enterprise environments, it’s common to manage dozens—or even hundreds—of AWS accounts. These accounts are often segmented by function (such as logging, networking, or security) or various business units, each maintaining its own set of accounts.

To further complicate things, most organizations separate environments (e.g. development, testing, production) into individual AWS accounts for better isolation and governance. Temporary or short-lived accounts are also frequently created for use cases like developer sandboxes, proof-of-concepts (POCs), or training labs.

To manage this complexity, many organizations turn to solutions like AWS Control Tower, the AWS Landing Zone Accelerator (LZA), or custom-built automation pipelines. These tools allow for the programmatic creation of AWS accounts at scale, helping teams maintain consistency and control across the organization.

However, simply creating accounts isn’t enough. As identity federation becomes the standard for secure access, there’s also a need to automate the setup of AWS IAM OIDC Providers in each account. Manual configuration is impractical at this scale. Automation is essential to ensure that OIDC configurations are applied consistently, securely, and efficiently across all accounts.

OIDC Configuration - Automated Solution

On the left, we have a sample account (Account A) which is a newly created account (created via automation).

On the right, we have a centralized OIDC factory account that implements the automation solution.

Process starts with creation or deletion of an IAM Web Identity Role in one of the newly created member accounts. AWS CloudTrail records this event. An Event Bus Event Rule captures these specific events and sends them to an Event Bus.

Event pattern to match the events is defined by:

{
  "source": ["aws.iam"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["iam.amazonaws.com"],
    "eventName": ["CreateRole", "DeleteRole"]
  }
}

The Event bus in Account A is connected to the OIDC factory account by setting the OIDC factory account Event Bus as its target.

In the OIDC Factory Account, we also have an event rule to capture the incoming events.

Event rule triggers a Lambda Function that then invokes one of two Step Function workflows. First workflow deals with events related to the creation of IAM Web Identity Roles. The second workflow deals with the events related to the deletion of IAM Web Identity Roles.

Workflow - Creation of IAM Web Identity Role

The first workflow consists of three Lambda functions:

• Create App Registration Lambda

  • Function calls an Entra ID API to register a new application.
  • The Lambda function returns a unique audience identifier for the Entra ID application.

• Add Audience to OIDC Provider Lambda

  • Function receives an audience identifier. It adds the audience identifier to the pre-deployed IAM OIDC Provider in the newly-created AWS account (Account A).

• Assign Role to Audience Lambda

  • Function updates the trust relationship in the IAM Web Identity Role by adding the audience identifier of the application registration.
  • This step is required because, unlike in the manual setup, the AWS user that creates the IAM Web Identity role does not have an audience identifier so users enter any dummy value. This will be overwritten few seconds later by the automation.

Workflow - Deletion of IAM Web Identity Role

The second workflow consists of two Lambda functions:

• Delete Application Registration Lambda

  • Invokes Entra ID API to delete the existing app registration.

• Remove Audience from OIDC Provider Lambda

  • Removes the audience identifier from the IAM OIDC Provider.

Summary

To recap, the key takeaways are:

• We should not be using Access Key ID/Secret Access Key as a method of authentication into AWS in any Production environments or environments that require higher degree of security.
• A better approach is to use the AWS IAM OIDC Provider to integrate with an external Identity Provider for system-to-system authentication.
• In complex and large scale environments, automation is useful to improve security and reliability of OIDC configurations.

Source Code

The source code to implement the solution for the OIDC factory account can be found in the aws-oidc-automation GitHub repo.