> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# About access keys

> Understand the two methods for creating access keys to authenticate against AI Object Storage

CoreWeave AI Object Storage uses **Access Keys** to authenticate requests for users and workloads. You can obtain Access Keys in three ways: by exchanging a CoreWeave API access token directly for temporary credentials, through Workload Identity Federation, or by creating a static key with an API access token.

## Direct access token exchange

<Info>
  To exchange a CoreWeave API access token directly for temporary AI Object Storage credentials, you need the `Object Storage Admin` role or an [organization access policy](/products/storage/object-storage/auth-access/organization-policies/about) that grants `cwobject:CreateAccessKey`.
</Info>

If you already authenticate with a [CoreWeave API access token](/products/storage/object-storage/auth-access/create-access-tokens), you can exchange it directly for temporary AI Object Storage credentials, without creating a separate static Access Key. CoreWeave recommends this method for principals that already have a CoreWeave API access token, because it removes the extra key-creation step and carries the principal's SCIM group memberships in the `iam:[ORG-ID]:groups` condition key for [group-based access control](/products/storage/object-storage/auth-access/bucket-access/bucket-policies#attribute-based-access-control).

* **Duration**: Keys are ephemeral and refresh automatically through the AWS container credentials provider. The keys are valid for 30 minutes.
* **Identity format**: `coreweave/[UID]`.

For setup steps, see [Direct access token exchange](/products/storage/object-storage/auth-access/manage-access-keys/api-access-token).

## Workload Identity Federation

[Workload Identity Federation](/products/storage/object-storage/auth-access/workload-identity-federation/about) is recommended for production workloads. Instead of storing long-lived credentials, your applications obtain tokens from your existing identity provider and exchange them for short-lived Access Keys that automatically expire.

### Workload Identity Federation with OIDC

OIDC is the recommended method for cloud-native and Kubernetes workloads. It uses short-lived tokens from your identity provider, such as GitHub Actions, a Kubernetes service account, or any OIDC-capable IdP, and exchanges them for temporary Access Keys with a 30-minute lifespan. OIDC is the standard approach for machine-to-machine authentication in cloud environments.

To generate keys with OIDC tokens, submit API requests to [`CreateAccessKeyFromOIDC`](/products/storage/object-storage/auth-access/workload-identity-federation/use-oidc-tokens). The endpoint accepts a `GET` request that includes the Organization ID and uses the token as the authorization header.

* **Duration**: Keys are ephemeral with a 30-minute lifespan.
* **Identity format**: `role/[ISSUER-URL]:[SUBJECT-USER-ID]`.

### Workload Identity Federation with SAML

For enterprise use cases, Object Storage also supports SAML assertions. SAML suits organizations that already have SAML-based identity infrastructure and require integration with enterprise IdPs such as Active Directory Federation Services or similar systems.

To generate keys with SAML assertions, submit API requests to [`CreateAccessKeyFromSAML`](/products/storage/object-storage/reference/object-storage-api-ref/cwobject/create-access-key-from-saml). These keys have the following characteristics:

* **Duration**: Keys are ephemeral with a maximum lifespan of 12 hours.
* **Identity format**: `role/[SAML-ROLE]`.
* **Requirements**: You must create a valid `configId` from a Workload Identity Federation configuration and pass it to the API request. For more information, see [Using Workload Identity Federation with SAML](/products/storage/object-storage/auth-access/workload-identity-federation/saml-workload-federation).

## Static access keys

<Info>
  Creating static access keys requires the `Object Storage Admin` role or an [organization access policy](/products/storage/object-storage/auth-access/organization-policies/about) that grants `cwobject:CreateAccessKey`.
</Info>

You can use an API access token to create persistent or time-limited Access Keys for Object Storage. To create a static Access Key, follow the steps in [Create access keys](/products/storage/object-storage/auth-access/manage-access-keys/create-keys).

To generate keys this way, submit API requests to [`CreateAccessKeyFromJWT`](/products/storage/object-storage/reference/object-storage-api-ref/cwobject/create-access-key). These keys have the following characteristics:

* **Duration**: Keys can be persistent, or they can be time-limited for up to 12 hours.
* **Identity format**: `coreweave/[PRINCIPAL-UID]`.
* **Requirements**: The API access token used to create the Access Key must have `write` permissions for Object Storage so users can upload data. For details, see [Create a CoreWeave API access token](/products/storage/object-storage/auth-access/create-access-tokens).

## Identity formats

You can use the Access Key format to audit and diagnose access. To find out how an Access Key was created, examine its identity format:

| Creation method              | Identity format               | Example                                                                                                             |
| ---------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **OIDC tokens**              | `role/[ISSUER-URL]:[SUBJECT]` | `role/https://oidc.cks.coreweave.com/id/3f9a2c14-7d6e-4b81-9a05-2c8e1f4b6d3a:system:serviceaccount:default:default` |
| **API access token**         | `coreweave/[PRINCIPAL-UID]`   | `coreweave/qT7mWZ4kRb9nXcVp2sLdH`                                                                                   |
| **CoreWeave internal tools** | `static/[KEY-ID]`             | `static/audit-logs`                                                                                                 |
| **SAML assertions**          | `role/[SAML-ROLE]`            | `role/SRE_ADMIN`                                                                                                    |

## Types of access keys

Access Keys fall into two categories based on creation method:

**Static keys** come from an API access token and are intended for development, testing, and manual operations:

* **Permanent keys**: Don't expire. Require manual rotation.
* **Temporary keys**: Expire after a set duration of up to 12 hours.

**WIF keys** come from Workload Identity Federation and are intended for production workloads. They're always ephemeral and never need to be stored or rotated:

* **OIDC-generated keys**: 30-minute lifespan, automatically refreshed by your application.
* **SAML-generated keys**: Up to 12-hour lifespan, automatically refreshed through SAML assertion exchange.

For production environments, use Workload Identity Federation for automated, secure key management. For less sensitive operations or for testing, you can use access keys created with an API access token.

## Manage your access keys

This section covers the full lifecycle of access key management:

* [Create access keys](/products/storage/object-storage/auth-access/manage-access-keys/create-keys): Generate new keys for users and workloads.
* [Revoke access keys](/products/storage/object-storage/auth-access/manage-access-keys/revoke-keys): Remove keys that are no longer needed.