Vaarta Vault
Sign inCreate your vault
Sign-in and access

Signed in through Identity Studio. Every app proves who it is.

You sign in to Vault through Identity Studio, with OAuth 2.0 and PKCE, passkeys and number matching. Each app then carries a token or a device key that works for Vault alone.

The connect flowMechanismsPolicies
Vaarta Vaultvia Identity Studio

Allow Vaarta Vault for Mac?

  • See your items' titles and the sites they are for
  • Show a password, key or card, after you approve on your phone
response_type=codecode_challenge_method=S256redirect_uri=http://127.0.0.1

Why it matters

The sign-in is where most break-ins start.

One identity, hardened once

The same sign-in, step-up and audit trail protect the vault and every app around it.

Tokens that only fit one lock

A token issued for Vault is refused anywhere else, and anything else is refused by Vault.

Stolen tokens die young

Access tokens last 30 minutes; refresh tokens rotate, and reusing an old one ends the whole chain.

How it works

Connecting the Mac app, or an agent.

  1. Your app1Opens your browserAuthorization code flow with a PKCE S256 challenge.
  2. Identity Studio2You sign inPassword or passkey, with a step-up where policy asks.
  3. You3Allow itA consent screen names the app and what it may do.
  4. Identity Studio4Code to loopbackBack to 127.0.0.1 only (RFC 8252); code valid 120 s.
  5. Identity Studio5Issues the tokenFor an agent, bound to the Vault endpoint (RFC 8707).
  6. Phone6Device goes liveThe Mac app registers its device key, then you match the number.
The Mac app uses the token once to register its device key, then signs every request with that key. Agents keep the token and refresh it.

The exact mechanisms

How each part of sign-in is built.

OAuth 2.0 and OpenID Connect, with PKCE

Authorization code flow. PKCE is S256 only, plain is refused, and it is mandatory for public clients such as the Mac app and agents. Redirect URIs must match exactly. Codes and refresh tokens are stored hashed; ID tokens are signed RS256.

S256 onlycode 120 saccess 30 minrefresh 30 days

Resource-bound tokens (RFC 8707)

A token request names one resource registered to the app, and the token's audience is that resource. The Vault endpoint accepts only tokens whose audience is itself; any other target is invalid_target.

aud = Vaultinvalid_target

Rotating refresh, real revocation

Refresh tokens rotate on every use. Presenting an old one revokes the whole chain and its session. Revocation (RFC 7009) ends the consent, every refresh grant, every credential grant and the session family, and answers the same for unknown tokens.

RFC 7009reuse detection

Native-app sign-in (RFC 8252)

The Mac app and the credential bridge register their own public client (RFC 7591) and receive the code on a loopback address. Pairing a computer from a hosted client is refused.

127.0.0.1 redirectRFC 7591

Passkeys

Sign in to your vault's console with a passkey. User verification is required, so a passkey also proves it is you, and it counts as a step-up.

WebAuthnuser verification required

Multi-factor and step-up

Step-up factors are a passkey, an authenticator code, a push to Vaarta Authenticator with number matching, or a recovery code. Revealing in the console needs a step-up no older than five minutes.

passkeyTOTPnumber-match pushrecovery code

Chrome and Android, without passwords in transit

The Chrome extension is connected from your signed-in console after a fresh step-up and keeps a P-256 key it cannot export. Vaarta Authenticator keeps its key in the phone's hardware, behind your biometric.

non-extractable keyAndroid Keystore

Our own invisible CAPTCHA

Early access

Sign-in, sign-up and password reset run Vaarta's own check: a small SHA-256 proof-of-work in the browser, nothing to solve, no tracking, nothing sent to a third party. Each challenge is signed, single-use, five minutes long and bound to the page and host. Today it checks and records; blocking is switched on per deployment.

16-bit proof-of-worksingle use5 min

Policies

Rules that decide who gets in, and from where.

Built on Identity Studio and shared with every app it protects.

Conditional access

Early access

Rules on roles, people, email domains, time zones, IP ranges, weekdays, hours, an unknown IP or a new device, with the action allow, require MFA, block or notify. Rules are evaluated and recorded today; enforcement is early access.

allowmfablocknotify

Location signal

Early access

An approximate city, region and country from the IP address, looked up offline, shown on your sessions and on the approval your phone sees. It is labelled approximate and is not used to decide access. IP geolocation by DB-IP.

DB-IP City Liteoffline lookup

CAPTCHA as a service

The same invisible check protects any app on Identity Studio, and each app can choose it or another provider for its hosted pages.

first partyTurnstilehCaptchareCAPTCHA
Identity Studio, the platform behind sign-in

In which planSign-in through Identity Studio comes with every plan.See plans →

See plans

Put every secret behind one tap.

Create your vault, link your phone, and bring everything in from where it lives today.

Create your vaultSee plans