Doppler

B SecretOps platform (API, CLI, secrets syncs)

On Team and Enterprise plans a workload can swap a token from any OIDC issuer you configure for a short-lived Doppler token, though the free plan only offers static tokens that never expire by default. Outbound syncs into AWS, GCP and Azure are keyless, but most CI and PaaS syncs (GitLab, Bitbucket, CircleCI, Cloudflare, Render, Fly.io) still want a pasted API token.

Docs: docs.doppler.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound Arequires Team or Enterprise (Service Accounts and Service Account Identities)

How a workload running anywhere authenticates to this product.

Service Account Identities accept an OIDC token from a preset provider or any custom discovery URL, validate required audience and subject claims plus optional custom claims (JSON Pointer for nested claims), and return a short-lived dp.said token via POST /v3/auth/oidc.

Issuers: any

docs.doppler.com checked 2026-10-13
“Identities allow a service account to authenticate to Doppler via OIDC without using a static API token. Any tool that can generate OIDC tokens (e.g., CI tools like GitHub or GitLab) is compatible with Doppler.”
docs.doppler.com checked 2026-10-13
“Select your provider (or provide a custom Discovery URL - you can verify the discovery data by clicking on the generated link below the field)”
docs.doppler.com checked 2026-10-13
“Audience and subject claims are required.”
docs.doppler.com checked 2026-10-13
“This feature is available with our Team and Enterprise plans.”
docs.doppler.com checked 2026-10-13
“Authenticate via a Service Account Identity with OIDC. Returns a short lived API token.”
docs.doppler.com checked 2026-10-13
“Doppler accepts these JWTs via its OIDC login flow and exchanges them for short-lived Doppler API tokens.”
docs.doppler.com checked 2026-10-13
“The Doppler Kubernetes Operator supports OIDC authentication, allowing your cluster to authenticate with Doppler using short-lived tokens instead of static API tokens.”

The custom Discovery URL is the bring-your-own-issuer path: Doppler documents CircleCI, GitHub Actions, GitLab, AWS IAM outbound identity federation (EC2) and any Kubernetes cluster whose issuer is publicly reachable. Federation is gated to Team and Enterprise; Developer (free) plan users are left with static Service Tokens (one config, optional expiry) or Personal/CLI tokens that carry the user's full read/write access. The Kubernetes Operator (Doppler's in-cluster agent) defaults to a static token stored in a Kubernetes secret ("tokenSecret", a service account token in production) and only uses OIDC if you configure it. The CLI, the GitHub secrets-fetch action and the Terraform provider all still accept static tokens too.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Keyless into the clouds: AWS via a cross-account IAM role with External ID, GCP via workload identity federation trusting Doppler's own OIDC issuer (per-connection subject), Azure via admin consent to Doppler's registered app or a federated credential; GitHub, Vercel, Heroku and Netlify via the vendor's app/OAuth install. Most other CI and PaaS syncs want a pasted long-lived API token.

docs.doppler.com checked 2026-10-13
“Doppler uses an IAM role you provide to assume into your account.”
docs.doppler.com checked 2026-10-13
“Enter your workplace slug for the External ID. You can obtain your workplace slug by visiting the Doppler dashboard.”
docs.doppler.com checked 2026-10-13
“Workload identity federation is recommended, since it leaves no credential stored in Doppler.”
docs.doppler.com checked 2026-10-13
“Because the subject contains the connection ID, trust you grant to one connection never extends to another.”
docs.doppler.com checked 2026-10-13
“Use this method if you'd rather give Doppler a service account key than set up federation.”
docs.doppler.com checked 2026-10-13
“You'll then be redirected to the Azure Portal to approve Doppler's access to your Azure Key Vault.”
docs.doppler.com checked 2026-10-13
“Doppler can authenticate to this integration without you storing a long-lived credential.”
docs.doppler.com checked 2026-10-13
“to provide access for syncing secrets from Doppler to a chosen repository.”
docs.doppler.com checked 2026-10-13
“Click Authorize which will take you back to the Doppler dashboard.”
docs.doppler.com checked 2026-10-13
“You can use Personal, Group, or Project access tokens from GitLab with this integration.”
docs.doppler.com checked 2026-10-13
“paste the API token you created in the previous step into the API Token field.”
docs.doppler.com checked 2026-10-13
“IAM User Secret access key”

Connectors checked. Keyless: AWS Secrets Manager, AWS Parameter Store, AWS IAM dynamic secrets/rotation and SQS log forwarding (IAM role + External ID); GCP Secret Manager (WIF recommended, service-account JSON key still offered) and GCP SA-key rotation (impersonation of a Doppler-owned service account); Azure Key Vault and App Service (consent to Doppler's app; Key Vault also offers a customer service principal with client secret), Azure service principal rotation/dynamic secrets (federated credential recommended, client secret optional); GitHub (Doppler GitHub App), Vercel, Heroku, Netlify (OAuth install). Static tokens: GitLab (PAT/group/project token), Bitbucket (access token), CircleCI (personal API token), Cloudflare Pages, Render, Fly.io, Terraform Cloud (org token), Railway, Supabase, Qovery (API tokens), Cloudflare token rotation (managing token), AWS EKM (IAM user access key pair). No Okta, Entra/M365 or Google Workspace connectors exist; those appear only as SAML/SCIM for human login. AWS External ID: confirmed that Doppler tells you to use your workplace slug, a value visible in your dashboard URL rather than a Doppler-generated per-connection secret. AWS's confused-deputy guidance wants an ID that is unique per customer and not chosen by the customer; that holds only if Doppler always sends the calling workplace's own slug and slugs cannot be chosen or reused. Doppler does not document either property, and every AWS connection in a workplace shares the same External ID. The GCP and Azure keyless paths, which use Doppler as an OIDC issuer with a per-connection subject, are the stronger design.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Service tokens and service account tokens can carry an expiry, but it is optional and the default is indefinite. No workplace policy to force a maximum token lifetime was found in the public docs; workplace settings only offer a bulk "Revoke Access Tokens" for personal and CLI tokens. docs.doppler.com checked 2026-10-13 “The datetime at which the API token should expire. If not provided, the API token will remain vaild indefinitely unless manually revoked” docs.doppler.com checked 2026-10-13 “An ephemeral Service Token can be created by setting an expiration time. Once the duration is reached, the token is automatically deleted.”
✓ Rotation via API	Service tokens also have create and delete endpoints; the dashboard offers a "roll" action for service account tokens. docs.doppler.com checked 2026-10-13 “Generate a new service account API token.” docs.doppler.com checked 2026-10-13 “Revoke an existing service account API token.”
✓ Scoped keys	Service tokens (one config, read-only by default) and service accounts (own workplace role, per-project and per-environment access, inline custom roles) are purpose-built machine principals. Personal and CLI tokens inherit the user's full read/write access. docs.doppler.com checked 2026-10-13 “A Doppler Service Token provides read-only secrets access to a specific config within a project.” docs.doppler.com checked 2026-10-13 “By default, service accounts do not have a workplace role or any project access granted to them and thus can't do anything until access is granted.”
✓ Last-used visible	Service account tokens expose last_seen_at through the API. The public service token list endpoint shows no last-used field, so dead per-config service tokens are harder to find. docs.doppler.com checked 2026-10-13 “last_seen_at” docs.doppler.com checked 2026-10-13 “List information about existing service account API tokens.”
✓ Leak revocation	Partner patterns (public-repo scanning) cover Doppler audit, CLI, personal, SCIM, service account and service tokens. Each token type has a distinct prefix (dp.st, dp.sa, dp.pt and so on) to aid scanning. docs.github.com checked 2026-10-13 “Doppler Service Account Token” github.blog checked 2026-10-13 “GitHub will forward access tokens found in public repositories to Doppler, who will revoke the tokens and email affected customers.”

Notes

Graded the Doppler cloud SecretOps platform and its REST API. Docs are public (docs.doppler.com, including Markdown copies and OpenAPI per endpoint), so nothing was gated. The A depends on the Team or Enterprise tier; a Developer-plan customer is effectively at D (static tokens, 4 of 5 hygiene checks, no forced expiry). Doppler is now itself an OIDC issuer (https://api.doppler.com) for outbound connections, but only the GCP and Azure-rotation docs use it; AWS connections still rely on the workplace-slug External ID.

Badge

[![wif.tax grade](https://wif.tax/badge/doppler-secrets.svg)](https://wif.tax/p/doppler-secrets/)