Use Workload Identity Federation with OIDC

With OIDC Workload Identity Federation, your workloads obtain an OIDC JWT from your Identity Provider (IdP) and exchange it for temporary AI Object Storage credentials. This eliminates the need to store long-lived secrets in your applications, which reduces the risk of credential leakage and simplifies key rotation. This guide is for administrators and platform engineers who need to grant non-CoreWeave workloads access to AI Object Storage without provisioning static keys. It walks through the complete workflow: configuring your OIDC provider, creating a WIF configuration in the Cloud Console, setting up organization access policies, and exchanging tokens for credentials. By the end, your workloads can authenticate using short-lived credentials derived from their existing OIDC identity.

How OIDC WIF works

Your workload obtains an OIDC token from your identity provider and sends it to the AI Object Storage WIF endpoint. CoreWeave validates the token against your WIF configuration, derives a role identity from the token’s iss (issuer) and sub (subject) claims, and returns a temporary Access Key / Secret Key pair for AI Object Storage. The role identity follows the format role/<ISSUER_URL>:<SUBJECT_USER_ID>. For example, if your IdP issues tokens with iss: https://idp.example.com and sub: svc-data-ingest, the derived role is role/https://idp.example.com:svc-data-ingest. Your organization access policies and optional bucket access policies determine what the returned credentials can do. These policies must reference this role as a principal.

Workload Identity Federation only generates temporary credentials. It doesn’t manage AI Object Storage organization access policies, bucket access policies, or Terraform state. You must configure policies separately and ensure they reference the correct WIF role principal.

Prerequisites

Before you begin, ensure you have:

A CoreWeave organization with AI Object Storage enabled.
Administrator privileges for your organization (the IAM Admin role and Object Storage Admin role, or equivalent legacy access).
The CoreWeave organization ID (find this on the Settings page in Cloud Console).
AWS CLI version 2.33.2 or later. If you use Python SDKs, make sure your SDK is at least boto3 >= 1.42.5.
An OIDC Identity Provider capable of issuing JWTs with the required claims (see Required OIDC claims).

Step 1: Configure your OIDC provider

Configure your IdP to issue JWTs for the workloads that need AI Object Storage access. CoreWeave uses these tokens to verify the identity of your workload before issuing temporary credentials, so the claims they carry must match the values in your WIF configuration. The tokens must include the standard claims listed in Required OIDC claims.

Required OIDC claims

The following standard OIDC claims are required. The aud claim is the one that varies most depending on your OIDC provider.

Claim	Description
`iss`	Issuer URL of your OIDC provider. Must match the issuer configured in your WIF configuration.
`aud`	Audience for the token. Must match the audience configured in your WIF configuration.
`sub`	Stable subject identifier for the workload (for example, a service account, client ID, or application ID).
`exp`	Expiration time (Unix timestamp). The token must not be expired.
`iat`	Issued-at time (Unix timestamp).

CoreWeave supports the optional nbf (not before) claim. If present, the token is invalid before that time.

Example JWT payload

{
  "iss": "https://idp.example.com",
  "aud": "coreweave-object-storage",
  "sub": "svc-data-ingest",
  "exp": 1640995200,
  "iat": 1640991600
}

This token produces the role identity role/https://idp.example.com:svc-data-ingest.

Step 2: Create a WIF configuration in Cloud Console

Next, register your IdP with CoreWeave. The WIF configuration specifies how CoreWeave validates tokens from your IdP, including which issuer URL to trust and which audience value to expect.

Log in to the Cloud Console and navigate to the Workload Federation page.
Click Create OIDC configuration. The configuration form opens:

Workload Identity Federation OIDC configuration creation page

Provide the following values:

Name: A unique name for the configuration.
Issuer URL: Your OIDC provider’s identifier URL, such as https://your-domain.okta.com or https://accounts.google.com. CoreWeave uses this to verify that your trusted identity provider issued the tokens and to fetch the provider’s JWKS for signature validation.
Client ID (Audience): The client identifier that tokens must target. CoreWeave validates that incoming tokens contain this value in their aud claim.
Description: A brief description of the configuration.

Click Create to save the configuration. After creation, CoreWeave generates a Config ID. You can view this ID on the Workload Federation page. At this point, CoreWeave can validate tokens from your IdP, but the WIF role doesn’t yet have permission to do anything.

Step 3: Create organization access policies

Organization access policies control what your WIF role can do. Before your workload can exchange OIDC tokens for credentials, you must grant the cwobject:CreateAccessKeyOIDC action to the WIF role. The principal for your OIDC role follows the format role/<ISSUER_URL>:<SUBJECT_USER_ID>, matching the role identity derived from your token. The following policy grants the WIF role permission to create temporary credentials through the OIDC endpoint. The cwobject: actions are global and must use "resources": ["*"]. Optionally, you can also grant other cwobject: actions to the WIF role.

{
  "policy": {
    "version": "v1alpha1",
    "name": "allow-oidc-key-creation",
    "statements": [
      {
        "name": "allow-create-access-key-from-oidc",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKeyOIDC"
        ],
        "resources": ["*"],
        "principals": [
          "role/https://idp.example.com:svc-data-ingest"
        ]
      }
    ]
  }
}

See Organization access policies for the full schema and additional examples.

Grant S3 permissions

After your workload can create credentials, you need policies that grant those credentials permission to access buckets. This policy grants read and write access to a specific bucket:

{
  "policy": {
    "version": "v1alpha1",
    "name": "data-ingest-read-write-my-bucket",
    "statements": [
      {
        "name": "allow-data-ingest-rw-my-bucket",
        "effect": "Allow",
        "actions": [
          "s3:Get*",
          "s3:List*",
          "s3:Put*",
          "s3:DeleteObject"
        ],
        "resources": [
          "[BUCKET-NAME]",
          "[BUCKET-NAME]/*"
        ],
        "principals": [
          "role/https://idp.example.com:svc-data-ingest"
        ]
      }
    ]
  }
}

Step 4: (Optional) Add bucket access policies

Usually, organization access policies are sufficient, and you can skip this step. However, you can layer on bucket access policies when you need cross-organization access to specific buckets or bucket-level lifecycle configuration. Organization access policies and bucket access policies have different syntax requirements:

Aspect	Organization access policies	Bucket access policies
Principals	Simple strings (for example, `role/https://idp.example.com:svc-data-ingest`)	Full ARNs (for example, `arn:aws:iam::[ORG-ID]:role/https://idp.example.com:svc-data-ingest`)
Resources	Short bucket names (`[BUCKET-NAME]`, `[BUCKET-NAME]/*`)	Full S3 ARNs (`arn:aws:s3:::[BUCKET-NAME]`, `arn:aws:s3:::[BUCKET-NAME]/*`)

See Bucket access policies for the full schema and examples.

Step 5: Configure your environment

After your IdP, WIF configuration, and organization access policies are in place, your workload can request temporary credentials from CoreWeave. In this final step, you configure your environment to use the temporary credentials, after which you can use any S3-compatible client to interact with your buckets.

Ensure you’re using the correct version of the AWS CLI. The minimum required version is awscli >= 2.33.2. If you use Python SDKs, the minimum required version is boto3 >= 1.42.5.
Check the AWS CLI version
```
aws --version
```
Set the following environment variables, filling in the values for your CoreWeave organization ID, the path to your JWT token file, and the CoreWeave region you’re using. This uses the AWS container credentials feature, so although the environment variables reference AWS CLI environment variables, you must fill in your CoreWeave-specific values:
Set the environment variables
```
export AWS_CONTAINER_CREDENTIALS_FULL_URI=https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]
export AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=[PATH-TO-JWT-TOKEN-FILE]

aws configure set s3.addressing_style virtual

export AWS_REGION="[AVAILABILITY-ZONE]"
export AWS_ENDPOINT_URL_S3="https://cwobject.com"
```
Test your configuration by listing your buckets:
List your buckets
```
aws s3 ls
```

On success, CoreWeave validates the token, derives the role identity, and returns temporary credentials. The Expiration field indicates when the credentials expire. The credentials inherit permissions from your organization access policies and any applicable bucket policies. If you receive an error message like the following, check that you’re using the correct version of the AWS CLI (awscli >= 2.33.2) or Python SDK (boto3 >= 1.42.5):

Unsupported host 'api.coreweave.com'.  Can only retrieve metadata from a loopback address or one of these hosts: 169.254.170.2, 169.254.170.23, fd00:ec2::23, localhost

Credentials request and response

This uses the AWS container credentials feature, which pulls from your configured credentials file and runs a GET request to the CoreWeave OIDC WIF endpoint as follows:

Request

GET https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]
Authorization: [JWT-TOKEN]

The response is a JSON object with the following fields:

Response

{
  "AccessKeyId":"CW...",
  "SecretAccessKey":"cw...",
  "Token": "",
  "Expiration":"2026-01-23T19:03:47Z",
  "attributes": {
    "cw-role":"<iss>:<sub>"
  }
}

Troubleshooting

If credential exchange or S3 operations fail, the following sections cover the most common causes and what to check.

Token exchange returns “permission denied”

If the /temporary-credentials/oidc call returns an error like {"code": 7, "message": "permission denied", "details": []}, check:

Missing cwobject permission: Ensure your organization access policy grants cwobject:CreateAccessKeyOIDC to the WIF role. This permission is required for the token exchange to succeed.
Token validity: Ensure the iss and aud claims match your WIF configuration. Verify the token isn’t expired (exp) and isn’t being used before nbf (if set).
WIF configuration: Confirm the Issuer URL and Client ID in your WIF configuration exactly match the values in your tokens.

Token exchange succeeds but S3 operations return AccessDenied

If you receive credentials but S3 operations fail, the issue is in your access policies. Check that at least one organization access policy:

Allows the needed s3:* actions (for example, s3:Get*, s3:List*, s3:Put*).
Uses the correct short-form resources ("my-bucket", "my-bucket/*").
Lists the correct WIF role in principals using the format role/<ISSUER_URL>:<SUBJECT_USER_ID>.

If you’re also using bucket access policies alongside organization policies, confirm they allow the required actions for the relevant principal ARNs. Be aware that explicit Deny statements can override other Allow statements. For a step-by-step guide to federating CKS workloads with AI Object Storage specifically, see CKS Workload Federation for AI Object Storage.

​How OIDC WIF works

​Prerequisites

​Step 1: Configure your OIDC provider

​Required OIDC claims

​Example JWT payload

​Step 2: Create a WIF configuration in Cloud Console

​Step 3: Create organization access policies

​Grant S3 permissions

​Step 4: (Optional) Add bucket access policies

​Step 5: Configure your environment

​Credentials request and response

​Troubleshooting

​Token exchange returns “permission denied”

​Token exchange succeeds but S3 operations return AccessDenied

​Related tutorials

How OIDC WIF works

Prerequisites

Step 1: Configure your OIDC provider

Required OIDC claims

Example JWT payload

Step 2: Create a WIF configuration in Cloud Console

Step 3: Create organization access policies

Grant S3 permissions

Step 4: (Optional) Add bucket access policies

Step 5: Configure your environment

Credentials request and response

Troubleshooting

Token exchange returns “permission denied”

Token exchange succeeds but S3 operations return AccessDenied

Related tutorials