Skip to main content
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:

​
Example: AWS

Devin can then run AWS commands without any stored credentials:
See the setup-aws-oidc documentation 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:
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.

​
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.
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.