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

# Cloud Authentication with OIDC

> Give Devin short-lived, keyless access to your cloud services via OpenID Connect

Devin can authenticate to cloud services using OpenID Connect (OIDC) workload identity federation instead of long-lived credentials. Each Devin session receives a short-lived identity token issued by Devin, which your cloud provider verifies and exchanges for temporary credentials. No static API keys or secrets need to be stored in Devin.

## How it works

1. Every Devin session automatically receives a short-lived **identity token**, signed by Devin and refreshed for the lifetime of the session.
2. Your cloud provider verifies the token against Devin's public OIDC issuer and grants temporary, scoped access.

Tokens identify the session through claims such as `org_id`, `devin_id`, and `requesting_user_email`, so you can write trust policies that grant access to your organization, or to specific sessions or users. Tokens expire automatically — there is nothing to rotate or revoke.

## Setup actions

Add the relevant action to the `initialize` section of your [environment blueprint](/onboard-devin/environment/blueprints):

| Action                                                                                  | Purpose                                                                      |
| --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| [`setup-aws-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-aws-oidc)     | AWS CLI and SDK auth via IAM `AssumeRoleWithWebIdentity`                     |
| [`setup-gcp-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-gcp-oidc)     | gcloud and Google Cloud SDK auth via Workload Identity Federation            |
| [`setup-vault-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-vault-oidc) | HashiCorp Vault CLI auth via the JWT/OIDC auth method                        |
| [`setup-jfrog-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-jfrog-oidc) | JFrog CLI auth via JFrog's OIDC token exchange                               |
| [`setup-devin-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-devin-oidc) | Base `devin-oidc` CLI, for services that trust Devin as an identity provider |

### Example: AWS

```yaml theme={null}
initialize:
  - uses: github.com/CognitionAI/actions/setup-aws-oidc@main
    with:
      role-arn: "arn:aws:iam::123456789012:role/devin-sessions"
      region: "us-east-1"
```

Devin can then run AWS commands without any stored credentials:

```bash theme={null}
aws sts get-caller-identity
```

See the [`setup-aws-oidc` documentation](https://github.com/CognitionAI/actions/tree/main/setup-aws-oidc) for the full AWS-side prerequisites and configuration options.

### Example: custom services

For your own APIs and internal services, use the base CLI to request a token for any audience your service accepts:

```bash theme={null}
devin-oidc token --audience my-api --subject-keys "org_id"
```

Configure your service to trust Devin's OIDC issuer and verify tokens against its published JWKS at `/.well-known/jwks.json`. The issuer is your Devin webapp origin — `https://app.devin.ai`, or your own domain for enterprise deployments (e.g. `https://yourdomain.devinenterprise.com`).

## Token claims

Tokens carry the following identity claims, which you can reference in trust policies and use to compose the token subject via `subject-keys`. The subject is built from `key:value` pairs of the selected claims — for example, `--subject-keys "org_id"` (the default) produces a subject like `org_id:a67b8de8-9483-4a9c-9662-51c3d2a45e88`.

| Claim                                          | Description                                                 |
| ---------------------------------------------- | ----------------------------------------------------------- |
| `org_id`                                       | Organization the session was launched in                    |
| `account_id`                                   | Account (enterprise or single-org customer) identifier      |
| `devin_id`                                     | The Devin session ID                                        |
| `devin_trigger`                                | How the session was started (e.g. `webapp`, `slack`, `api`) |
| `requesting_user_id` / `requesting_user_email` | The user who started the session                            |
| `service_user_id`                              | Service user, for API-initiated sessions                    |

## Security properties

* **No long-lived credentials**: tokens are short-lived and refreshed automatically; nothing needs to be rotated or revoked when a session ends.
* **Scoped access**: audience-scoped tokens are only valid for the specific service they were requested for, and your trust policies control exactly which identities can be granted access.
* **Auditable identity**: tokens carry the session, organization, and requesting user, so cloud-side audit logs attribute every action to a specific Devin session.

<Note>
  Enterprise deployments with custom domains have a dedicated per-account signing key, and the token issuer is your custom Devin URL. Contact your Devin administrator or Cognition support for your issuer URL and organization ID.
</Note>