1Password

D 1Password for machines (Service Accounts, Connect, SDKs, CLI)

Workloads read and manage vault items with a static service account token (ops_...) or a Connect server token. Expiry is optional and never enforced, and 1Password is not a GitHub partner for revoking leaked tokens. A Business-tier preview, Credential Broker, accepts OIDC tokens from your own issuer, but it only reads Environments and still needs a static integration key. Sync into AWS Secrets Manager is keyless (SAML role federation).

Docs: 1password.dev · Checked 2026-10-22 · source YAML · dispute via PR

Inbound D

How a workload running anywhere authenticates to this product.

Static service account token (OP_SERVICE_ACCOUNT_TOKEN) for the CLI, SDKs, CI/CD and Kubernetes integrations, or a static Connect server access token (OP_CONNECT_TOKEN) presented to a self-hosted Connect server, which itself holds a long-lived 1password-credentials.json. Credential Broker (public preview, Business) can verify a workload's OIDC token from any issuer, but only to read Environments, and it also requires a static integration key.

1password.dev checked 2026-10-22
“You can manage secrets with [1Password Service Accounts](#1password-service-accounts) or [1Password Connect servers](#1password-connect-servers).”
1password.dev checked 2026-10-22
“Each service account has a [service account token](/service-accounts/security.md#service-accounts-and-token-generation) that you can provide as an environment variable for authentication.”
1password.dev checked 2026-10-22
“A service account token is an authentication string that represents an SRPx object that's serialized and Base64 URL encoded.”
1password.dev checked 2026-10-22
“Create a secret for your GitHub repository named `OP_SERVICE_ACCOUNT_TOKEN` and set it to the service account token value.”
1password.dev checked 2026-10-22
“A Connect server access token is an authentication string that allows the Connect server to authenticate with 1Password services, such as the [Connect REST API](/connect/api-reference.md).”
1password.dev checked 2026-10-22
“The `encCredentials` contains the encrypted credentials necessary for the associated service account.”
1password.dev checked 2026-10-22
“When a team member runs a workflow, 1Password validates the identity of the workload using an [OIDC token. ](https://openid.net/developers/how-connect-works/).”
1password.dev checked 2026-10-22
“Define the identity requirements (claims) that must be met to verify a workload.”
1password.dev checked 2026-10-22
“The token value is your integration key, which is required to decrypt secrets in your team's workflows.”
1password.dev checked 2026-10-22
“1Password Credential Broker is only supported in the [1Password JavaScript SDK ](https://github.com/1Password/onepassword-sdk-js) at this time.”
1password.dev checked 2026-10-22
“Service accounts can only be granted read access to Environments.”

Graded on the weakest path a workload must use to automate the product: creating, reading or editing vault items (the core of 1Password's machine API, the Terraform, Pulumi, Ansible, Kubernetes and CI integrations) works only with a service account token or a Connect token, both long-lived bearer secrets. Credential Broker (public preview, 1Password Business) is real bring-your-own-issuer OIDC: an admin enters any issuer URL, 1Password discovers its JWKS, checks claims you define and an audience, and GitHub Actions has a preset. It does not lift the grade. It only reads 1Password Environments (not vaults or items), only through the JavaScript SDK and the GitHub load-secrets action, and every workflow also needs a static, org-wide "integration key" (OP_INTEGRATION_KEY) stored as a CI secret. Because 1Password is end-to-end encrypted, that key decrypts the secrets, so a long-lived secret stays in the path even on the OIDC route; on its own it would be C at best. The Users API uses OAuth client_credentials with a client secret (C) and the Events API uses static bearer JWTs; both are side APIs and do not change the grade. No cloud workload identity (AWS role, GCP or Azure identity, Kubernetes service account token) login is documented for service accounts or Connect.

Outbound A

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

The only push integration, Environments sync to AWS Secrets Manager (beta), assumes an IAM role you create that trusts a 1Password Secrets Sync SAML provider, pinned with a saml:sub condition. No AWS key is handed to 1Password.

1password.dev checked 2026-10-22
“Authentication to your AWS account happens through SAML. You'll need to register the 1Password Secrets Sync SAML provider within your AWS account.”
1password.dev checked 2026-10-22
“Value**: Go back to the 1Password configuration page and select **Copy SAML subject**.”
1password.dev checked 2026-10-22
“This allows you to set up the integration once per environment, only requiring AWS credentials to create the IAM resources.”
1password.dev checked 2026-10-22
“Securely sync your environment variables to [AWS Secrets Manager](/environments/aws-secrets-manager.md).”
1password.dev checked 2026-10-22
“You can use Kubernetes integrations to deploy a [1Password Connect Server](/connect.md) or a [1Password Service Account](/service-accounts.md) to a Kubernetes cluster.”
1password.dev checked 2026-10-22
“When you connect a 1Password Environment to an OpenShell gateway, 1Password transfers custody of the Environment's secrets to OpenShell for a defined time-to-live (TTL).”

Checked: Environments sync to AWS Secrets Manager (keyless, SAML 2.0 federation into a customer IAM role with a saml:sub condition rather than an External ID; the sample policy grants secretsmanager actions on Resource "*", which you can narrow). No GCP, Azure, Vercel, GitHub or other secret-sync destination is documented. Everything else runs in your infrastructure and pulls from 1Password with an inbound token: the Kubernetes Operator and Secrets Injector, Connect server, CI/CD plugins (GitHub Actions, CircleCI, Jenkins), Terraform, Pulumi, Pulumi ESC, Ansible and Postman. Credential Broker's GitHub Actions integration asks only for the GitHub organization name (1Password verifies GitHub's OIDC tokens; no GitHub App or token is handed over), and NVIDIA OpenShell is a local gateway you run. A single keyless cloud integration earns A under the rubric ("every cloud it supports"); adding a key-based destination would drop it to B.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Service account, Connect and Events API tokens can all carry an expiry, but it is optional. The service account wizard and docs never require one, and Events API tokens default to Never. No account policy that forces a maximum token lifetime is documented. A changeable default is not an enforced expiry (precedent: doppler-secrets). 1password.dev checked 2026-10-22 “You can set an expiry to a service account using the `--expires-in` flag.” 1password.dev checked 2026-10-22 “When you create a Connect server access token, you can set the token's expiration time to 30, 90, or 180 days.” 1password.dev checked 2026-10-22 “Expires After**: (Optional) Choose when the token will expire: 30 days, 90 days, or 180 days. The default setting is Never.”
✓ Rotation via API	Passes on Connect tokens, which `op connect token create`, `list` and `delete` fully cover without a browser. Service accounts are weaker: `op service-account create --expires-in` mints a new one from the CLI, but "Rotate Token" and "Revoke Token" are documented only on 1Password.com, and the CLI has no service-account delete or rotate command. So a service-account rotation job can issue short-lived replacements but cannot revoke the old token. All of these commands need a signed-in human (owner, admin or delegated) account; a service account cannot create another service account. No public REST management API exists. A reviewer may reasonably fail this on the service-account path, which would make the card 2/5 and F. 1password.dev checked 2026-10-22 “Issue a new token for a Connect server.” 1password.dev checked 2026-10-22 “Revoke a token for a Connect server.” 1password.dev checked 2026-10-22 “Create a service account to gain programmatic access to your secrets using 1Password CLI.” 1password.dev checked 2026-10-22 “Revoking a service account token immediately removes its access to 1Password vaults.”
✓ Scoped keys	Service accounts are purpose-built machine principals with per-vault read, write or share permissions (immutable after creation) and cannot reach Personal, Private, Employee or the default Shared vault. Connect tokens can be cut down to a subset of the server's vaults and to read-only or write-only. 1password.dev checked 2026-10-22 “A service account is a type of user account that's meant for programmatic access.” 1password.dev checked 2026-10-22 “A service account can only read items from vaults it has READ access to.” 1password.dev checked 2026-10-22 “For example, you can grant a Connect token access to a specific subset of the vaults the Connect server has access to.”
✓ Last-used visible	Borderline pass. There is no documented last-used timestamp on the token itself, but each service account's overview shows recent activity and its usage report shows when it last accessed items, which is enough to find a dead service account. Connect tokens have no documented equivalent beyond item-usage events in the Events API. 1password.dev checked 2026-10-22 “The service account overview page shows information about the service account, such as the vaults and [1Password Environments](/environments.md) it can access, vault permissions, and recent activity.” 1password.dev checked 2026-10-22 “Usage reports for service accounts include information on the number of vaults and items a service account can access, an overview of vaults where a service account has accessed items, when those items were last accessed, and the action performed.”
✗ Leak revocation	The first column (Partner) is ✗: GitHub detects ops_ service account tokens for user alerts and push protection, but does not report leaks in public repos to 1Password for revocation. Connect and Events API tokens are not in the table at all. docs.github.com checked 2026-10-22 “\| 1Password \| 1Password Service Account Token \| 1password_service_account_token \| ✗ \| ✓ \| ✓ \| ✗ \| ✗ \| ✗ \|” 1password.dev checked 2026-10-22 “1Password uses a unique string format to help code analyzers find accidental credential exposure.”

Notes

One card for 1Password's machine-access surface: Service Accounts, Connect server, the Go, JS and Python SDKs, the CLI and the integrations built on them, plus Environments and the Credential Broker preview. The Events API (static bearer JWT, optional expiry defaulting to Never, scoped to event types, issued and revoked on 1Password.com) and the Users API (OAuth client_credentials, client secret rotatable with a 6-hour grace) are side APIs noted here but not graded. Inbound moves to A if Credential Broker (or an equivalent) reaches vault items, drops the static integration key, and leaves preview; enforced token expiry, CLI revoke for service accounts and joining GitHub's partner program would make it 5/5 at D. All docs were public (www.1password.dev Markdown copies).

Badge

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