1Password vs Azure Key Vault for Automated Logins: Which Vault for Which Team

Azure Key Vault is now a supported identity source in Wire, alongside 1Password. If you're weighing 1Password vs Azure Key Vault, the feature lists won't help much - both hold secrets, both are encrypted, both are revocable. The real difference is how each one answers a single question: what is this integration allowed to read?

Short answer: pick 1Password if you want a one-step setup where the token carries its own scope, and Azure Key Vault if your access is already governed through Entra ID and you want per-vault roles your auditors can read. The setup, the failure modes and the governance story all follow from that one choice.

1Password: the token carries its own scope

You create a Service Account in 1Password, grant it specific vaults, and paste the token. That's the whole setup.

It's one step because a 1Password Service Account token is self-scoping. The token already knows which vaults it can reach, so when Wire verifies it, the list of vaults comes back for free. Nothing to configure, nothing to enumerate, nothing to keep in sync - the grant lives in the token and travels with it.

These aren't plain bearer tokens, either. They carry SRP auth material and an unlock key, because 1Password's model is zero-knowledge: items are decrypted client-side. Wire uses 1Password's official SDK to do that, which also handles region routing - .com, .eu, .ca - off the token itself. Your master password is never involved and never seen.

Revocation matches the simplicity: delete the Service Account, and every read fails immediately.

Azure Key Vault: you define the scope, because Azure won't

Azure takes four steps, and each one is there for a reason: Azure gives Wire no way to discover the scope on its own.

There is no data-plane API that lists the vaults a principal can reach. Enumerating them means going through Azure's management plane, which needs a second token scope and subscription- or resource-group-level Reader - a far larger grant than "read some secrets." Asking for it to populate a dropdown would be the wrong trade.

So Wire doesn't ask. You supply the vault URLs at connect time, and that list is the scope. Wire refuses to read from any vault outside it, even if the credential technically could.

Step three is the one people skip, and it produces the most confusing failure in the whole flow. Watch for Key Vault Reader - it sounds like the right role and grants metadata only. You'll be able to list every secret name and get a 403 on every value. If a vault still uses the older access-policy model instead of RBAC, the equivalent is an access policy granting Get and List on secrets.

Why Azure needs two words for "no"

In Azure, authentication and authorization are separate systems. Microsoft Entra ID answers who are you and issues a token good for about an hour. Each vault's own RBAC answers what may you read. A completely valid credential returns 403 on a vault it was never granted.

The split matters in practice, because Wire treats the two responses differently:

Collapse those two into "access denied" and one missed role assignment tears down a connection that works everywhere else. Kept apart, a missing grant tells you which vault and which role - instead of sending you off to regenerate a client secret that was never the problem.

What a secret looks like on each side

1Password has structured Login items: a username field, a password field, URLs. Wire reads the fields it needs and that's that.

An Azure secret is one opaque string. It has no fields at all. So Wire exposes it three ways at once. If the value parses as a JSON object, each key becomes a field. Otherwise the whole string is available as value. And every tag is exposed under tag:, namespaced so a tag can never shadow a real field.

That mapping is what lets one binding model cover whatever layout you already have - a JSON blob, a bare value with the username in a tag, or two separate secrets - without us imposing a convention on your vault. The Azure Key Vault guide walks through all three.

One caution on tags: tags are metadata, not secrets. Anyone who can list the vault can read them. A username in a tag is reasonable. A password is not.

The comparison, in one table

Feature summary based on 1Password and Azure Key Vault documentation as of October 2026, not independently benchmarked figures.

So which one should you pick?

Choose 1Password if your team already runs on it, you want to be connected in under a minute, and the people who manage credentials are the same people who'll set this up. A Service Account token doesn't expire unless you give it an expiry when you create it, so there's no forced renewal on a clock. For most teams this is the right answer and the shortest path.

Choose Azure Key Vault if your secrets are already governed by Azure, your identity story runs through Entra ID, or you need what Azure's model is built around: per-vault RBAC assigned by the people who already assign roles, versioned secrets, and sovereign cloud support for US Government or China regions. If a compliance framework asks who granted access to what and when, Azure answers in the system your auditors already look at.

The four-step setup is the cost of that, and it's mostly a one-time cost. Do set a reminder for the client secret - Entra caps them at 24 months and doesn't surface the expiry through the token exchange, so Wire can't warn you about it yet. When it comes due, rotate the source instead of reconnecting. The source ID stays the same, so every identity bound to it keeps working.

Both are equally safe in the way that matters: Wire holds a reference and an encrypted, scoped token, reads the credential in memory at login, and keeps only the session. Rotation is transparent on both - Wire always reads the current version, so when the value changes in your vault, the next login picks it up.

You can also connect more than one. Multiple sources per account is supported, which is how teams run separate dev and prod vaults, or migrate from one provider to the other without a cutover.

Once you've picked: the full setup, the provider's own quirks, and what to do when something fails are in the dedicated guides - Using 1Password with Wire and Using Azure Key Vault with Wire.

Connect a vault. Both providers are live now, so the question from the top, what this integration is allowed to read, gets answered in the system your team already uses to answer it. Connecting either takes one pass through your dashboard, and you can run both side by side while you decide.

→ Get started with Wire · Docs

Frequently Asked Questions

What is the main difference between 1Password and Azure Key Vault in Wire?

How each one sets scope. A 1Password Service Account token is self-scoping, so the vaults it can reach come back when Wire verifies it. Azure has no data-plane API that lists the vaults a principal can reach, so you supply the vault URLs at connect time, and that list is the scope.

Which Azure role does Wire need on each Key Vault?

Key Vault Secrets User, assigned on each vault. Key Vault Reader is the common mistake: it grants metadata only, so you can list every secret name and get a 403 on every value. Vaults on the older access-policy model need an access policy granting Get and List on secrets instead.

Do the vault credentials expire?

A 1Password Service Account token doesn't expire unless you give it an expiry when you create it. Azure client secrets are capped at 24 months, and Entra doesn't surface the expiry through the token exchange, so set a reminder and rotate the source in Wire when it comes due.

What happens when a password is rotated in the vault?

Nothing changes on the Wire side. Wire always reads the current version, so when the value changes in your vault, the next login picks it up.

Can one account connect both 1Password and Azure Key Vault?

Yes. Multiple sources per account is supported, which is how teams run separate dev and prod vaults, or migrate from one provider to the other without a cutover.

Does Wire store the secrets from your vault?

No. Wire holds a reference and an encrypted, scoped token, reads the credential in memory at login, and keeps only the session.