Single sign-on

Single sign-on lets the people in your organization sign in to the VAIF Studio console through your own identity provider, over OpenID Connect. It works with any OpenID Connect provider, such as Okta, Microsoft Entra ID or Google Workspace. Single sign-on is on Agency, Studio+ and Enterprise.

This is for signing in to the VAIF Studio console. Your app’s own users sign in with project authentication.

How it works

1. An organization owner sets up a connection: your provider’s issuer URL, the client ID and client secret of an app registered with the provider, and your email domain (for example acme.com).
2. The owner proves the domain belongs to the organization by publishing a DNS TXT record.
3. The owner tests the connection and turns it on.
4. From then on, anyone who chooses Continue with your company on the console sign-in page and enters an address at that domain is sent to your provider, and comes back signed in.

VAIF checks each ID token against your provider’s published signing keys, checks the issuer, audience, expiry and nonce, and uses PKCE for the code exchange.

Set it up

Open Organization settings, then Security. Owners make changes; admins can see the settings but not change them.

1. Register an app with your provider

Create an OpenID Connect web application at your provider. Set its redirect URI to the Redirect URI the Security page shows; it must match exactly. Copy the issuer URL, client ID and client secret the provider gives you.

2. Create the connection

Choose Set up single sign-on and enter:

Field	Meaning
Issuer URL	Your provider’s OpenID Connect issuer. VAIF reads /.well-known/openid-configuration from it before saving, so a mistyped issuer is caught here rather than at sign-in
Client ID and Client secret	From the app you registered. The secret is write-only: you can replace it, but never read it back
Email domain	People whose email is at this domain sign in through your provider
Role for new members	The role people get the first time they sign in through your provider
Create members on first sign-in	On: someone who signs in for the first time joins the organization with that role. Off: only people you invited can sign in this way

Public mailbox domains, such as gmail.com, can’t be used, and a domain another organization has already verified can’t be claimed.

3. Verify the domain

The Domains card shows a TXT record to publish on your domain:

acme.com.  TXT  "vaif-domain-verification=<token>"

Publish it at your DNS provider, wait until it is visible, and check it from the Domains card. Single sign-on stays off until the domain is verified.

4. Test and turn it on

Choose Test sign-in to run a real sign-in through the connection, then turn the connection on from its menu.

Two-factor authentication

If someone has two-factor authentication on their VAIF account, they enter their code after returning from your provider, just as with a password sign-in. Require two-factor on the same page makes every member set it up.

Require single sign-on

Once a connection is on, an owner can require it. Members at the domain must then sign in through your provider, and password sign-in is refused for them, in the console and in the CLI. Before it takes effect, the page says how many sessions it signs out and for how many people.

• Break-glass owners: pick the owners who can still sign in with their password and second factor if your provider is down. Every break-glass sign-in is recorded in the audit log and emailed to every owner.
• Members outside your domain: review members whose email is not at a verified domain. You can block them unless you allow each one, and restore anyone you blocked.

Turn it off

The owner can turn off or delete the connection at any time from the same page, including after the organization moves to a plan without single sign-on. Members can then sign in with their VAIF password again.