Using 1Password with Wire: Service Accounts, Scoping, and What We Can Actually See

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 actually grants, which is worth understanding before you paste it.

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.

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.

Step two 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. 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

Paste the token into Wire and it's verified immediately - a live call to 1Password, before anything is written down.

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 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 is worth sitting with, because it 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.

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. That's it - every read fails from that moment, and no cooperation from us is required.

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

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.

After rotating a revoked token, re-verify the existing source rather than creating a new one - 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.

Set it up. If you already have a 1Password Service Account, connecting takes about a minute.

→ Get started with Wire · Docs