Skip to content
Esc
↑↓navigate↵open⌘Jpreview
On this page

Authentication

Every way to sign in to varsafe — dashboard login methods, account protection, sessions, and the CLI's browser and token sign-in.

CLI v7.8.1

People sign in to the dashboard in the browser, and the CLI signs in through that same browser, so a password never reaches a terminal. Machines use API tokens.

You are Sign in with Lasts
A person in the dashboard Password, GitHub, GitLab, Google, Bitbucket, a passkey, or your company’s SSO 7 days, renewed while you use it
A person at a terminal varsafe login, approved in the browser Up to 180 days; ends after 90 days unused
A CI job, server or script An API token in the environment The lifetime chosen at creation
An AI agent An OAuth grant over MCP, or an API token 90 days without use, or the token’s lifetime

Dashboard login methods

Method Notes
Email and password Add two-factor authentication for a second factor
GitHub, GitLab, Google, Bitbucket Click the provider’s button on the sign-in page
Passkey Sign in with passkey, or pick the passkey your browser offers in the email field
SSO SAML 2.0 or OIDC through your company’s identity provider, on the Team plan. See Single sign-on

SSO is detected from your email. Type your work email on the sign-in page: if your company has set up SSO for that domain, the page offers Continue with SSO. Use password instead remains available.

OAuth login

Click a provider button, approve varsafe at the provider, and you are signed in.

If an account with the same email already exists under another method, the provider sign-in is refused rather than silently attached to that account, which stops anyone from taking over an account through a provider that vouches for an email they do not own. The sign-in page says There is already a varsafe account with this email: sign in the way you did before, then connect the provider from your profile.

Connected accounts

Connected accounts on your Profile lists GitHub, GitLab, Google and Bitbucket, and which of them are connected.

  • Connect sends you to the provider to approve, then back to your profile. The provider account must use the same email address as your varsafe account, and the provider must have confirmed it. Your own email must be confirmed first.
  • Disconnect stops that provider signing you in. It is refused when your account has no password and no other provider, and it needs a session signed in within the last day.

A provider account already connected to another varsafe account cannot be connected to yours.

Connecting or disconnecting a provider here is recorded in your audit log as auth.provider_connected or auth.provider_disconnected, naming the provider, and is not kept if the record cannot be written.

Confirming your email

A new account can be used straight away. varsafe sends a confirmation link, valid for 24 hours. You need to have confirmed your email before you:

  • invite someone or accept an invite
  • create a team
  • transfer ownership
  • configure SSO
  • connect an AI agent
  • connect a sign-in provider

Passkeys

Passkeys sign you in with Touch ID, Face ID, Windows Hello or a hardware key such as a YubiKey, with no password to phish or reuse. Each passkey is bound to the varsafe domain.

Adding a passkey

  1. Open your Profile in the dashboard
  2. In the Passkeys card, click Add passkey
  3. Optionally name it (“MacBook Touch ID”, “YubiKey 5”)
  4. Follow your browser’s prompt

Register more than one, on different devices, so losing one device does not lock you out. Passkeys can be renamed or deleted from the same card.

Passkey-only mode

Passkey-only mode refuses every sign-in that is not a passkey: password, GitHub, GitLab, Google, Bitbucket and SSO. A refused sign-in says This account is in passkey-only mode. Sign in with one of its passkeys.

  • Requirements: at least 2 passkeys and a password on the account. The Passkey-only mode control appears in the Passkeys card once both are in place.
  • Enabling it revokes every session, including the current one. Sign back in with a passkey.
  • While it is on, a session signed in with a passkey can still change the password and turn two-factor authentication on or off.
  • Disabling it takes your password.

Two-factor authentication (2FA)

Two-factor authentication adds a time-based one-time code (TOTP) to password sign-in. It is available on accounts that have a password.

Enable 2FA

Start setup

Open your Profile and start two-factor setup.

Enter your password

Add varsafe to your authenticator

Scan the QR code with an authenticator app (1Password, Google Authenticator, Authy and the like), or type the secret shown under it.

Confirm a code

Enter the 6-digit code from the app.

Save the backup codes

Save the 10 backup codes, then confirm with I’ve saved the codes. Keep them in a password manager or another safe place, not on the device that holds the authenticator.

Using 2FA

When Do
Signing in After your email and password, enter the current 6-digit code. Codes change every 30 seconds
You lose your authenticator Sign in with a backup code. Each one signs you in once
Turning 2FA off From your Profile, turn two-factor off and confirm with your password

Session management

Viewing sessions

The Active Sessions card on your Profile lists every browser signed in to your account, with its device and browser, IP address and last activity. Current marks the one you are using.

Revoking sessions

  • The revoke button on a row (Revoke session) signs that browser out
  • Revoke all other sessions keeps only the current one

A revoked session stops working within 30 seconds.

Session properties

  • Lifetime: a session ends 7 days after it was last extended. Using it extends it, at most once an hour, so an active session stays signed in and an idle one ends within a week.
  • Renewal: changing the password with Sign out all other devices, or turning two-factor authentication on or off, replaces the session you are using with a new one. The audit log records it as auth.session_renewed, with the reason and the session it replaced, not as a sign-in.
  • Concurrent sessions: the plan sets a threshold of 5 per person on Developer (200 on Team). It is a prompt, not a ceiling: past it the dashboard shows Session limit reached after sign-in and offers to revoke old sessions, but you can continue and a new session is still created.

CLI logins are listed separately, in the CLI Sessions card on your Profile.


Password change and reset

Changing your password, from your Profile, keeps your other sessions signed in unless you tick Sign out all other devices. Tick it if you are changing the password because you think someone else knows it. Each change is recorded in your audit log as auth.password_changed, saying whether the other devices were signed out; a reset is recorded as auth.password_reset.

Resetting a forgotten password:

  1. Click Forgot password? on the sign-in page
  2. Enter your email address
  3. Open the link in the email within 1 hour and choose a new password

CLI authentication

The CLI has two ways in: a browser login for people, and an API token for machines. There is no email and password login in the terminal.

Browser login (default)

varsafe login
  1. The CLI shows a confirmation code such as 7KQ2M-X9D4F and opens the dashboard approval page (it prints the URL if no browser opens)
  2. In the browser, sign in if needed, check that the code matches the one in your terminal, and approve
  3. The CLI picks up the approval at once, over a live connection that falls back to polling every few seconds

The code expires after 10 minutes. varsafe login --force signs in again when a login already exists.

A CLI login is its own credential, not a copy of your browser session. It lasts at most 180 days from approval and ends sooner if the machine goes 90 days without using it. Revoke one any time from the CLI Sessions card on your Profile. Removing you from a team revokes your CLI login for that team.

API token

For CI/CD and automation, use an API token. Pick the input that keeps the value out of shell history:

Where you run How the token gets in Stored on the machine
CI/CD The VARSAFE_API_TOKEN environment variable, from your CI secret store No. There is no login step
Workstation varsafe login with a masked prompt, standard input or VARSAFE_TOKEN Yes, as the login

No login step at all. Set VARSAFE_API_TOKEN (or VARSAFE_TOKEN, read when the first is not set) from your CI secret store:

export VARSAFE_API_TOKEN=vs_at_vsafe_example
varsafe run -- npm run build

The variable is used when the machine has no stored login. If varsafe login has stored a credential, that credential takes precedence and the variable is ignored; varsafe whoami shows which one a command will use. See the CI/CD guide.

varsafe login -T
# or
varsafe login --token-prompt

Masked input; nothing lands in shell history.

Stdin pipe

secret-manager read varsafe-token | varsafe login -t -
# or from a file in RAM
varsafe login -t - < /dev/shm/token.txt

- tells the CLI to read the token from standard input.

From VARSAFE_TOKEN

VARSAFE_TOKEN=vs_at_vsafe_example varsafe login

A bare varsafe login with VARSAFE_TOKEN set stores that token as the login.

Why there is no --token <value> flag

# Rejected, by design
varsafe login --token "$VARSAFE_API_TOKEN"

An inline value is visible in shell history and to any process that can read ps output, so the CLI refuses it and points to the options above. --token with no value means “prompt me”; --token - means “read stdin”.

Credential storage

The CLI keeps its credential in ~/.varsafe/varsafe.db. Which credential it is decides how it is stored, how long it lasts and what signing out does:

Browser login Machine token API token (login -T)
Stored Encrypted with AES-256-GCM, with the key in the operating system keychain Unencrypted, in the same file, inside ~/.varsafe, a directory only your user can read Encrypted with AES-256-GCM, with the key in the operating system keychain
Lasts At most 180 days from approval, and ends sooner after 90 days unused At most 30 days The lifetime chosen at creation
Signing out Revokes it on the server, then clears it from the machine Revokes it Clears it from the machine only

The encryption key is kept in the operating system keychain (macOS Keychain, or the Secret Service on Linux), so a copy of the file alone does not reveal the credential. varsafe doctor checks that the keychain works on this machine.

The machine token is what a browser login falls back to on a machine with no keychain: there is no keychain to hold a key, so it is stored unencrypted. To limit what a copied file is worth, it is restricted to one team and the projects and environments you approved.

Signing out

varsafe logout

For an API token stored with varsafe login -T, logout clears the token from the machine only: revoke the token itself in the dashboard if the machine is no longer trusted.


Deleting your account

Open your Profile, go to Danger Zone, and type delete my account to confirm. Deletion is permanent.

What sign-in does not do yet

  • No new-device check. A correct password from an unfamiliar device is not challenged by email. Turn on two-factor authentication or use passkeys.
  • SSO is not enforced. Setting up SSO for a domain does not stop its users from signing in with a password or a provider.
  • No provider account under another email. A provider can be connected only with the same email address as your varsafe account.