Federating non-human identities with external IdPs using ID tokens in AWS, GCP, and Azure

In today’s cloud-native world, many applications and services no longer rely solely on human users to interact with infrastructure. Instead, non-human identities — such as automation agents, continuous integration (CI) pipelines, backend services, AI systems, and Internet of Things (IoT) devices perform many of these tasks autonomously. These non-human identities act similarly to users but represent software entities rather than people.

Managing and securing these non-human identities is becoming increasingly complex, especially when your infrastructure spans multiple cloud providers like AWS, Google Cloud Platform (GCP), and Microsoft Azure. Traditional methods that rely on static credentials—like long-lived access keys or tokens—introduce significant security risks. These credentials are difficult to rotate regularly, can be accidentally leaked, and lack fine-grained control and visibility.

This is where ID tokens come into play. An ID token is a cryptographically signed token issued by an identity provider that proves the identity of the requester. By leveraging OpenID Connect (OIDC), you can use ID tokens to establish trust between your non-human identities and cloud providers securely.

In this blog post, we will explore how to federate non-human identities using an external OIDC-compliant Identity Provider (IdP). This federation approach allows your workloads to authenticate once with the external IdP and then securely access cloud resources across AWS, GCP, and Azure. You will learn how each cloud provider supports this federation, why establishing and maintaining trust is crucial, and how to design a system that provides temporary, auditable, and least-privilege access across clouds.

Along the way, we will walk you through key components such as AWS Security Token Service (STS), GCP Workload Identity Federation, and Microsoft Entra ID (Azure AD), explaining how they fit into this architecture.

What are non-human identities?

When we talk about non-human identities, we refer to software-based entities that perform automated operations without direct human intervention. Examples include:

• Continuous integration and deployment pipelines (CI/CD)
• Backend micro-services and APIs
• Artificial intelligence and machine learning agents
• IoT devices and edge compute nodes
• Autonomous workflows and scheduled jobs

As described by the Riptides, these workloads:

• Are not tied to any individual user or session.
• Often operate across organizational or security boundaries.
• Need strong cryptographic proof of their identity to be trusted.
• Require fine-grained permissions and detailed auditability when accessing cloud APIs and resources.

Historically, many organizations have relied on static credentials such as API keys or long-lived tokens for these workloads. However, these approaches suffer from serious drawbacks:

• They are cumbersome to rotate and manage.
• They increase the risk of credential leakage.
• They provide little to no auditing or control over how credentials are used.

Federation offers a better solution by allowing these workloads to delegate authentication to a trusted external identity provider. This shifts credential management to a centralized, secure system that issues short-lived, verifiable tokens, improving security and operational agility.

Federation, trust, and external identity providers

At the core of federated identity systems is the concept of trust. For cloud providers like AWS, GCP, and Azure to accept identity claims issued by an external IdP, there must be an explicit and secure trust relationship in place.

Here’s how the pieces fit together:

• The external Identity Provider (IdP) authenticates your non-human identities and issues them a signed ID token following the OIDC standard. This token contains verified claims about the identity, such as who they are and what they are allowed to do.
• The cloud provider receives this ID token and validates its authenticity and integrity. It checks the token’s issuer, signature, audience, expiration, and relevant claims to confirm the identity.
• The trust relationship between the cloud provider and the external IdP is explicitly configured. This includes specifying the trusted issuer URLs, accepted audiences, and claim mappings. Without this trust setup, the cloud provider will reject tokens from unknown or untrusted IdPs.

Benefits of using federated identities for non-human access

Switching to federated identities for your workloads brings a wide range of security, operational, and compliance advantages compared to traditional static credentials.

1. Improved security posture

• Eliminates long-lived static credentials:
  Static API keys or tokens are often stored in code repositories, configuration files, or environment variables — making them vulnerable to accidental exposure or theft. Federated identities rely on short-lived, cryptographically signed tokens that expire quickly, drastically reducing risk if a token is compromised.
• Cryptographic proof of identity:
  ID tokens issued by trusted identity providers contain digitally signed claims that cloud providers can validate. This strong proof prevents impersonation and unauthorized access.
• Fine-grained access control:
  Federation lets you map token claims to precise permissions in the cloud. This means workloads get only the access they need — following the principle of least privilege — rather than broad or unlimited rights.

2. Simplified credential management

• Centralized identity provider:
  Instead of managing separate credentials for every cloud environment or service, all authentication is delegated to a single external IdP. This simplifies onboarding, rotation, and revocation processes.
• Automatic credential rotation:
  Because tokens are short-lived and dynamically issued on demand, you don’t need manual key rotations or complex secret distribution mechanisms.
• Unified audit trails:
  All authentication activity funnels through the external IdP, making it easier to track who accessed what and when — vital for security audits and compliance.

3. Cross-cloud and cross-organization scalability

• Seamless multi-cloud access:
  With federation, your non-human identities authenticate once against your external IdP and then can gain access to multiple cloud providers without juggling separate credentials for each.
• Supports complex trust boundaries:
  If your infrastructure spans multiple teams, business units, or partner organizations, federated identities help you enforce trust and permissions consistently while respecting boundaries.

4. Better developer and operator experience

• Reduced operational overhead:
  Developers and DevOps teams no longer have to handle cumbersome credential management or worry about secrets leaking in logs or repositories.
• Easier integration:
  Many cloud-native tools and platforms now natively support OIDC federation, allowing smoother onboarding and less custom glue code.

In summary, adopting federated identities is a foundational step toward a modern, secure, and scalable cloud infrastructure that respects best practices for identity and access management. The security, operational efficiency, and flexibility benefits compound quickly — especially as you expand your cloud footprint or embrace automation and AI-driven workflows.

Setting up federation with AWS, GCP, and Azure

Now that we’ve covered the core concepts and benefits of federating non-human identities with an external Identity Provider, let’s look at how to put this into practice.

Each major cloud provider—AWS, Google Cloud Platform (GCP), and Microsoft Azure—offers its own mechanisms and services to establish trust with external OIDC-compliant IdPs and to securely consume ID tokens for access control.

In the following sections, we will explore the key components, configuration steps, and best practices for setting up federation on each platform:

• How AWS uses Security Token Service (STS) to assume roles based on external ID tokens.
• How GCP’s Workload Identity Federation enables token exchange without long-lived service account keys.
• How Azure Entra ID (Azure AD) supports external identity providers for workload authentication.

By understanding these workflows, you will be equipped to implement secure, scalable cross-cloud identity federation tailored to your infrastructure.

1. AWS: Web Identity Federation with OIDC

AWS enables federated non-human identity by using IAM roles for Web Identity in combination with OIDC identity providers. This lets you delegate authentication to an external IdP and securely grant temporary permissions to workloads based on ID tokens.

Setup steps:

1. Create an OIDC identity provider in IAM

‍This step establishes a trusted relationship between AWS and your external Identity Provider. By registering the IdP’s issuer URL, client IDs, and certificate thumbprint, AWS can validate the ID tokens it receives during authentication.

aws iam create-open-id-connect-provider \
    --url "https://example-idp.com/oidc" \
    --client-id-list "my-client-id" \
    --thumbprint-list "9e99a48a9960b14926bb7f3b2e5e5b9e7e5e5e5e"

‍

Note: To get the certificate thumbprint required here, you can use OpenSSL as follows:

openssl s_client -connect example-idp.com:443 </dev/null | \
openssl x509 -fingerprint -noout | \
sed 's/SHA1 Fingerprint=//' | tr -d ':' | tr 'A-Z' 'a-z'

‍

2. Create an IAM role with a Trust Policy for the external IdP‍

Next, create an IAM role that your federated identities will assume. The trust policy explicitly grants permission for AWS to accept ID tokens issued by your external IdP for this role. It defines which identities (based on claims like sub and aud) are allowed to assume the role.

aws iam create-role \
    --role-name my-oidc-role \
    --assume-role-policy-document file://trust-policy.json

‍

Example trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/example-idp.com/oidc"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "example-idp.com/oidc:sub": "my-workload-identity",
          "example-idp.com/oidc:aud": "my-client-id"
        }
      }
    }
  ]
}

3. Attach IAM policies to the role to define permissions

Attaching policies to the role defines what actions the federated identities can perform once authenticated. This step ensures that the identities have the necessary permissions to access AWS resources, such as read-only access to Amazon S3 in this example.

aws iam attach-role-policy \
    --role-name arn:aws:iam::943962173050:role/my-oidc-role \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

‍

4. Assume the role using the ID Token

Finally, your non-human identity uses the OIDC ID token obtained from the external IdP to assume the IAM role and receive temporary AWS credentials with the permissions defined above.

This can be done via the AWS CLI:

aws sts assume-role-with-web-identity \
    --role-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/my-oidc-role\
    --role-session-name my-session \
    --web-identity-token "<ID token received from IdP>"

or programmatically via AWS SDKs.

‍

Authentication sequence diagram:

2. GCP: Workload Identity Federation

Google Cloud Platform provides a robust way to federate external identities through Workload Identity Pools and Providers. This enables non-human identities authenticated by an external OIDC IdP to access GCP resources without requiring long-lived service account keys.

Setup steps:

1. Create a Workload Identity Pool and an OIDC provider

The Workload Identity Pool acts as a container for external identities, while the Provider configures the trust relationship with your external IdP by specifying its issuer URL and allowed audiences. This setup allows GCP to accept and validate ID tokens issued by your IdP.

gcloud iam workload-identity-pools create my-pool \
    --project="my-project" \
    --location="global" \
    --display-name="My Pool"

gcloud iam workload-identity-pools providers create-oidc my-provider \
    --project="my-project" \
    --location="global" \
    --workload-identity-pool="my-pool" \
    --display-name="My Provider" \
    --issuer-uri="https://example-idp.com/oidc" \
    --allowed-audiences="my-client-id" \
    --attribute-mapping="google.subject=assertion.sub"

‍

2. Grant the workload identity user role to allow identities from the pool to impersonate a GCP service account

This step links your external identities to a specific GCP Service Account. By granting roles/iam.workloadIdentityUser on the service account to the external identity (via the workload identity pool and claim), you enable the federated identity to act as the service account and inherit its permissions.

gcloud iam service-accounts add-iam-policy-binding "my-service-account@my-project.iam.gserviceaccount.com" \
    --project="my-project" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principal://iam.googleapis.com/projects/<PROJECT_NUMBER>/locations/global/workloadIdentityPools/my-pool/subject/my-workload-id"

‍

3. Authenticate using the external ID token to impersonate the service account

Instead of using a long-lived key file, you exchange your external OIDC ID token for short-lived GCP credentials tied to the service account. This can be done via the Google Cloud SDK’s gcloud CLI or programmatically using Google’s client libraries.

Here is an example using the gcloud CLI to authenticate with the external token.

gcloud auth login --cred-file cred-config.json

‍

Example cred-config.json:

{
  "universe_domain": "googleapis.com",
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/<PROJECT_NUMBER>/locations/global/workloadIdentityPools/my-pool/providers/my-provider",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com.com:generateAccessToken",
  "credential_source": {
    "file": "token.jwt",
    "headers": {},
    "format": {
      "type": "text"
    }
  }
}

Save the actual OIDC token issued by your external identity provider into token.jwt.

‍

Authentication sequence diagram:

3. Azure: Federated Identity with User-Assigned Managed Identity (UAMI)

Microsoft Entra Workload Identity Federation now supports federating external non-human identities to a User-Assigned Managed Identity (UAMI). This allows workloads outside Azure — such as CI/CD pipelines or automation tools — to authenticate to Azure without using client secrets.

Setup steps:

1. Create a User-Assigned Managed Identity

az identity create \
  --name my-uami \  
  --resource-group my-rg \
  --location westeurope

‍

Get the identity's client ID and resource ID:

az identity show --name my-uami --resource-group my-rg \
  --query "{clientId:clientId, id:id, principalId:principalId}"

‍

2. Add a federated identity credential

This step connects the external IdP to the UAMI by configuring Entra to accept signed ID tokens from your external system.

az identity federated-credential create \
 --name my-federated-cred \
 --identity-name my-uami \
 --resource-group my-rg \
 --issuer https://example-idp.com/oidc \
 --subject "my-workload-identity" \
 --audiences "api://AzureADTokenExchange"

‍

3. Assign roles to the UAMI

Use Azure RBAC to grant the UAMI access to Azure resources. For example, to allow read access to your subscription:

az role assignment create \
 --assignee-object-id <principalId-from-step-1> \
 --assignee-principal-type ServicePrincipal \
 --role Reader \
 --scope /subscriptions/<your-subscription-id>

4. Use an external OIDC-issued ID token to get an Azure access token

Once your external identity has received an ID token from the external IdP, it can authenticate to Azure using az login and the --federated-token flag. This allows your workload to assume the federated User-Assigned Managed Identity (UAMI) without using a client secret.

az login \
 --service-principal \
 --username <client-id-of-uami> \
 --tenant <tenant-id> \
 --federated-token <ID token received from IdP>

‍

Replace <client-id-of-uami> with the UAMI's client ID, <tenant-id> with your Azure AD tenant ID, and <ID token received from IdP> with the actual OIDC token issued by your external identity provider.

‍

Authentication sequence diagram:

‍

Comparison of Federation across AWS, GCP, and Azure

Best practices

To ensure secure and scalable federation for non-human identities, follow these guidelines:

• Use short-lived tokens: Keep token lifetimes as short as practical to reduce the risk from token leakage or misuse.
• Restrict token claims: Match on precise subjects and audiences to avoid accepting tokens from unintended sources.
• Minimize role scope: Grant only the minimal permissions required using tightly scoped IAM roles or service account bindings.
• Monitor and audit usage: Leverage cloud-native audit logs to track token issuance, role assumptions, and access behavior.
• Rotate identity provider metadata: Plan for regular updates to OIDC metadata (keys, issuers, thumbprints) to handle IdP changes securely.

Final thoughts

Federating non-human identities is no longer optional — it's essential for operating securely in today’s multi-cloud environments. By adopting OIDC-based federation with ID tokens from a trusted external Identity Provider, you enable:

• Ephemeral, automatically expiring credentials
• Centralized identity lifecycle management
• Fine-grained access control
• Full auditability of automated access

The true power of federation lies in how well you define trust relationships and claim mappings. A CI/CD job running in GitHub Actions should not inherit the same access as a production AI pipeline — even if both use tokens issued by the same IdP.

As the number of machine actors grows, federation becomes a pillar of secure identity architecture. Build with it early, use it consistently — and revisit your trust boundaries often.

Looking ahead

At Riptides, we’re building a system that treats non-human identity as a first-class citizen in cloud-native environments. Riptides issues and manages SPIFFE-based workload identities, assigning them to services and agents at runtime. When needed, these identities can be represented as OIDC-compatible ID tokens, allowing them to act as federated identities with major cloud providers.

Under the hood, these ID tokens are exchanged for short-lived, cloud-native credentials — such as AWS STS credentials, GCP access tokens, or Azure Entra tokens — and securely delivered to the workload, with no static credentials required.

In a follow-up post, we’ll explore how Riptides enables this end-to-end federation flow, and how it helps teams eliminate manual credential handling while maintaining security, auditability, and least-privilege access across cloud providers.