If you're running workloads in AWS, you're already managing IAM credentials. Wouldn't it be great if those same credentials could authenticate your services with Cloudsmith without creating, storing, or rotating yet another API key?

That's exactly what AWS's new outbound identity federation enables when paired with Cloudsmith's OIDC support. Your AWS workloads can now exchange their IAM identity for short-lived Cloudsmith tokens on the fly. No long-lived secrets sitting in environment variables. No API keys to rotate. Just cryptographically signed, time-limited credentials.

What's Happening Under the Hood?

The magic happens through AWS STS (Security Token Service), which can now issue signed JSON Web Tokens (JWTs) that external services like Cloudsmith can verify and trust. Here's the flow:

1. Your AWS workload calls STS and asks for an OIDC token, specifying Cloudsmith as the intended audience
2. STS returns a cryptographically signed JWT containing your AWS identity information
3. You pass this token to Cloudsmith's OIDC endpoint
4. Cloudsmith fetches AWS's public verification keys and validates the token's signature
5. If everything checks out, Cloudsmith hands back a short-lived JWT you can use for API calls
6. You're authenticated, no API key required

Setting Things Up

There are three pieces to configure: AWS permissions, AWS external identity federation, and Cloudsmith OIDC settings. Let's walk through each.

Grant Permission to Request Tokens

Your AWS role or user needs permission to call the sts:GetWebIdentityToken API. Add this policy to any IAM principal that needs to authenticate with Cloudsmith:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetWebIdentityToken",
      "Resource": "*"
    }
  ]
}

Enable Outbound Identity Federation in AWS

Before your account can issue these external identity tokens, you need to flip the switch. Head to the IAM console, select Account settings under Access management, and enable outbound identity federation.

Once enabled, AWS generates a unique issuer URL for your account. This URL hosts the OIDC discovery endpoints that external services use to verify your tokens. It looks something like https://{UUID}.tokens.sts.global.api.aws. Keep this URL handy since you'll need it for the Cloudsmith configuration.

This endpoint exposes the standard /.well-known/openid-configuration which allowed Cloudsmith to fetch the required metadata to verify received tokens.

Configure OIDC in Cloudsmith

Now tell Cloudsmith to trust tokens from your AWS account. Navigate to your Cloudsmith organization settings at Settings > Authentication > OpenID Connect and click Create Provider Settings.

Fill in the following:

Getting Your Tokens

With everything configured, here's how to actually authenticate from your AWS workloads.

Grab a Token from AWS STS

Using the AWS CLI:

OIDC_TOKEN=$(aws sts get-web-identity-token \
  --audience cloudsmith \
  --signing-algorithm RS256 \
  --query 'WebIdentityToken' \
  --output text)

• --audience must match what you configured in Cloudsmith's required claims. We used cloudsmith above.
• --signing-algorithm accepts either RS256 or ES384. Both work fine.

Exchange It for a Cloudsmith JWT

Now swap that AWS token for Cloudsmith credentials:

SERVICE_SLUG="your-service-account-slug"
ORG_SLUG="your-cloudsmith-org"

CLOUDSMITH_JWT=$(curl -s -X POST \
  "https://api.cloudsmith.io/openid/${ORG_SLUG}/" \
  -H "Content-Type: application/json" \
  -d "{\"oidc_token\": \"${OIDC_TOKEN}\", \"service_slug\": \"${SERVICE_SLUG}\"}" \
  | jq -r '.token')

Replace your-service-account-slug with your Cloudsmith service account slug, and your-cloudsmith-org with your Cloudsmith organization identifier.

Verify It Works

Test your credentials:

curl -s -H "Authorization: Bearer ${CLOUDSMITH_JWT}" \
  "https://api.cloudsmith.io/v1/user/self/" | jq

If everything's configured correctly, you'll see something like:

{
  "authenticated": true,
  "name": "aws-pipeline",
  "slug": "aws-pipeline",
  "slug_perm": "Ne67GhNtJOe7",
  "self_url": "https://api.cloudsmith.io/v1/user/self/"
}

Where This Shines

This pattern works anywhere you have an AWS IAM identity. The short-lived nature of both tokens keeps things secure, and you're leveraging identity you're already managing.

EC2 instances can use their instance profile to request OIDC tokens. Add the token exchange to your startup scripts or application initialization.

ECS and Fargate tasks work the same way through task roles. Grab a token during container startup or lazily when you first need Cloudsmith access.

Lambda functions can request tokens during cold start or on-demand within your function code. The overhead is minimal because both API calls are quick.

CodeBuild, CodePipeline, and other AWS services with an IAM role attached can participate. Build pipelines become much cleaner without injected API key secrets.

Wrapping Up

AWS outbound identity federation combined with Cloudsmith's OIDC support is a clean solution for a common problem. You're extending trust from identity you already manage, exchanging it for short-lived credentials exactly when you need them, and eliminating the operational overhead of API key management.

No more secrets in environment variables. No more key rotation schedules. No more "who has access to that API key?" conversations.

For more details, check out the AWS outbound identity federation documentation and Cloudsmith's OIDC guide.