Using 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. This guide 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.

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. What the returned credentials can do is determined by your organization access policies and optional bucket access policies, which must reference this role as a principal.

Workload Identity Federation only generates temporary credentials. It does not 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)
Your AWS CLI version updated to at least 2.33.2. If using 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. The tokens must include the standard claims described below.

Required OIDC claims

The following standard OIDC claims are required. Note that 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).

The optional nbf (not before) claim is supported. 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 would produce the role identity role/https://idp.example.com:svc-data-ingest.

Step 2: Create a WIF configuration in Cloud Console

Create an OIDC Workload Identity Federation configuration to tell CoreWeave how to validate tokens from your IdP.

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

Screenshot of the 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 tokens were issued by your trusted identity provider and to fetch the provider’s JWKS for signature validation.
Client ID (Audience): The client identifier that tokens must be intended for. 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, a Config ID is generated. You can view this ID on the Workload Federation page.

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 via 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

Once 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

In most cases, organization access policies are sufficient. 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

Once your IdP, WIF configuration, and organization access policies are in place, your workload can request temporary credentials from CoreWeave. All you need to do is configure your environment to use the temporary credentials, and then you can use any S3-compatible client to interact with your buckets.

Ensure you are using the correct version of the AWS CLI. The minimum required version is awscli >= 2.33.2. If using Python SDKs, it requires 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 are using. Note: 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 are 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

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 is not expired (exp) and is not 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 (e.g., 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 are using bucket access policies in addition to 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.

Storage

Documentation Index

​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