If your team already runs on 1Password, connecting it to Wire is the shortest path to automating anything behind a login. The setup is one field. The interesting part is what that one field grants, so here is the short answer before you paste it: a 1Password Service Account token lets Wire see only the vaults you granted, Wire reads one login item at the moment it signs in, and you can cut access from 1Password in one step without asking us.
Use a Service Account, never your own login
1Password Service Accounts exist for exactly this: machine access to specific vaults, separate from any human's account. Create one, grant it only the vaults Wire needs, and you have a credential that is scoped from birth and revocable without touching anyone's personal login. Scoped from birth is literal here: 1Password doesn't let you add vaults or change permissions on a Service Account after it's created, and it can't be granted your built-in Personal, Private or Employee vault, or the default Shared vault, at all.
The alternative - handing over a person's 1Password credentials - is wrong in every direction. It grants everything that person can see, it breaks when they change their password, it dies when they leave, and it makes the audit trail meaningless because every access looks like them.
Picking the vaults is the whole security decision. A Service Account sees the vaults you grant it and nothing else, so the narrowest useful grant is a dedicated vault holding only the logins you intend to automate. Setting that up once makes every later conversation about access a short one.
What the token actually is
An ops_ token is not a bearer token, and the difference matters.
1Password is zero-knowledge: items are encrypted such that 1Password's own servers can't read them, and decryption happens on the client. So the token carries auth material and an unlock key rather than being a simple API password. 1Password's security docs describe it as the Account Unlock Key, the Secure Remote Password details and the account's keyset, serialized into a JWT and Base64-encoded behind the ops_ prefix. Wire uses 1Password's official SDK to handle it, which means the decryption happens inside our process using their code - and your account's master password is never involved, never transmitted, and never seen by us.
The SDK also handles regional routing on its own. If your account lives on .eu or .ca rather than .com, the token knows, and requests go to the right place with nothing to configure.
Connecting
| # | Step | What it is |
|---|---|---|
| 1 | Create | A Service Account in 1Password |
| 2 | Scope | Grant only the vaults Wire needs |
| 3 | Copy | The ops_… token, shown once |
| 4 | Connect | Paste into Wire - verified live |
Paste the token into Wire and it's verified immediately - a live call to 1Password, before anything is written down. From code it's the same check: POST /v1/wire/identity-sources with "provider": "1password" and the token, as shown in the Connect Source reference.
That ordering is deliberate. If the token is wrong, expired, or scoped to nothing, no record is created at all. You don't end up with a broken connection sitting in your account looking configured. Either it worked at the moment you gave it to us, or it doesn't exist here.
What gets stored on success is the token, encrypted with AES-256-GCM, plus the list of vaults it can reach (scope_metadata.vaults in the API) so the interface can show you your own scope without calling 1Password every time you open a page.
Pointing an identity at a login
With the source connected, you browse your own vaults inside Wire - vaults, then login items - and pick the item that backs a given account.
Two things make this less tedious than it sounds. The item list filters by the site's domain, so connecting a supplier portal surfaces the matching logins rather than everything you own. And browsing never opens anything: Wire reads titles and metadata to render the picker, nothing more. Item contents are read at one moment only - when logging in.
What Wire stores is a reference: this identity is backed by that item, in that vault. Not a copy of the item. Not the fields. A pointer.
What Wire reads, and when
At login time - and only then - Wire reads the referenced item and pulls the username and password fields. Those go straight into the sign-in, in memory. The site issues a session, Wire encrypts and stores the session, and the credential is discarded.
The read is scoped to one item. Connecting a Service Account with access to a vault of 200 logins doesn't mean Wire reads 200 logins. It means Wire could read the ones you point identities at. Every actual read is one item, at one moment, for one sign-in.
And every one of those reads is recorded in your own vault's activity trail, which inverts the usual arrangement. Most vendors ask you to trust their access logs, about their own behaviour, generated by them. Here the record of what we read and when lives in your system, written by your provider, on infrastructure we have no ability to alter. In 1Password, the Service Account's item usage report shows the vaults where it has accessed items, when those items were last accessed, and the action performed.
You never have to take our word for what we accessed. You can just look.
Rotation stops being an event
The reference names an item, not a version, so Wire always reads what's in the vault right now.
Change the password in 1Password and there is nothing to update on our side. The current session keeps working until it expires - the site doesn't know the password changed - and the next sign-in uses the new value automatically.
This is the main practical reason to use a vault at all. A stored copy of a password goes stale silently, then fails, then keeps retrying a wrong password until the site locks the account. A reference can't go stale.
Revoking
Delete the Service Account in 1Password, or revoke its token. That's it - every read fails from that moment, and no cooperation from us is required. From our side, disconnecting the source deletes the stored token too, and 5 ways to revoke Wire's access walks through what each option removes.
Wire notices rather than retrying into a wall: the next rejected read marks the source revoked, and identities depending on it surface as broken instead of quietly returning stale data. Existing sessions keep working until they expire, since they're already-issued sessions the site accepts - if you need those gone too, delete the identities in Wire, or sign out everywhere on the site itself.
When something goes wrong
| You see | Usually means | Whose move |
|---|---|---|
SOURCE_TOKEN_REJECTED | At connect: token mistyped, expired, or already revoked | Yours |
SOURCE_ITEM_NOT_FOUND | Item or vault moved or deleted | Yours |
SOURCE_FIELD_MISSING | Not a Login item - no username/password (see missing_fields) | Yours |
SOURCE_AUTH_FAILED | Service Account deleted or token revoked - the source is now marked revoked | Yours |
The third one catches people out. Secure Notes and custom item types can hold a username and a password without being Login items, and Wire reads the standard login fields. If an item looks right but won't resolve, check its type first. The error's missing_fields list names what Wire couldn't find.
After issuing a new token in 1Password, rotate it into the existing source rather than creating a new one - a successful rotation returns a revoked source to active, and the identities stay bound and start working again.
More than one connection
Multiple 1Password sources per account are supported, and there are three good reasons to use them: separate dev and prod vaults, separate Service Accounts per client or team so revocation is surgical, and overlapping tokens during a rotation so nothing breaks mid-swap.
Each is scoped independently. Revoking one doesn't touch the others. And if part of your organisation keeps its secrets in Azure Key Vault instead, Wire reads from that too. 1Password vs Azure Key Vault for automated logins covers which vault suits which team.
So the one field from the start grants less than it looks: a token that only sees the vaults you chose, one item read per sign-in, a record of each read in your own 1Password, and an off switch you hold.
Frequently Asked Questions
What is a 1Password Service Account?
A machine account in 1Password that reads only the vaults granted to it when it was created. Its access can't be widened afterwards, and its token starts with ops_ and is shown only once, so save it straight away.
Can Wire read every item in a granted vault?
Wire can reach the vaults you grant, but it reads only the items you point identities at, one item at the moment of sign-in. Browsing your vaults in Wire uses titles and metadata only, never secret values.
Does Wire store the passwords from 1Password?
No. Wire stores the Service Account token encrypted with AES-256-GCM, the list of vaults it can reach, and a reference to each bound item. The username and password are read into memory for the sign-in and discarded, and only the resulting session is stored, encrypted.
What happens when a password changes in 1Password?
Nothing needs updating in Wire. The current session keeps working until it expires, and the next sign-in reads the new value from the vault automatically.
How do you revoke Wire's access to 1Password?
Delete the Service Account or revoke its token in 1Password, and every read fails from that moment. Wire marks the source revoked. Sessions already issued keep working until they expire, unless you delete the identities in Wire or sign out everywhere on the site.
Does it work with 1Password accounts on .eu or .ca?
Yes. The token carries the account's sign-in address and the SDK routes requests to the right region, so there is nothing to configure.
Next in Identity & Access: Identities, Credentials, and Sessions - the data model behind all of this.
Set it up. If you already have a 1Password Service Account, connecting takes about a minute.
→ Get started with Wire · 1Password setup docs