Single sign-on & passkeys

WatchTower15 supports single sign-on so your team signs in with the identity provider they already use, and so you can enforce that company accounts authenticate the way your security policy requires.

What’s supported

• Sign in with Google — personal Gmail and Google Workspace accounts.
• Sign in with Microsoft — Microsoft Entra ID (Azure AD) work/school accounts and personal Microsoft accounts.

SSO uses the OAuth 2.0 / OpenID Connect authorization-code flow. It is a second way to sign in to an existing account — see the important note on provisioning below.

SSO signs in invited users; it does not create them

WatchTower15 SSO is match-only. A user must already have been invited to the organisation. When they sign in with Google or Microsoft, WatchTower15 matches them to their existing account by email address; if no account exists, the login is refused with a message to ask an administrator for an invite. There is no just-in-time auto-provisioning.

To start a new organisation, create an account with your email address. An address on a verified domain of an organisation that has disabled password login can’t register separately: the confirmation email asks you to request an invitation from that organisation’s administrator instead, and no account is created.

Verified organisation domains

SSO enforcement is anchored on domains you’ve proven you control, via a DNS TXT record:

1. In organisation settings, add your domain (e.g. example.com). WatchTower15 issues a one-time verification token.
2. Publish a DNS TXT record:

   host:  _wt15-verification.example.com
   value: wt15-site-verification=<your-token>

3. Click Verify. WatchTower15 resolves the record and marks the domain verified.

Verified domains are re-checked automatically every week. If the TXT record disappears, the domain’s verification lapses (and any enforcement that depended on it fails safely open to password login rather than locking people out). A domain can be claimed by only one organisation at a time.

Enforcement controls

Two per-organisation switches turn verified domains into policy:

Control	Effect
Restrict users to verified domains	SSO logins are only accepted when the sign-in email’s domain is one of your verified domains. Only enforced once you have at least one verified domain.
Disable password login (SSO-only)	Members whose email is on a verified domain can no longer sign in with a password — they must use Google or Microsoft.

Both controls are scoped to actual organisation membership as well as domain, a deliberate design choice: a contractor on an outside email domain is unaffected, and the switches can’t be used to lock out or interfere with users in another organisation.

Email-first login

The sign-in screen is email-first. A user enters their email; WatchTower15 resolves whether that address belongs to an organisation that requires SSO and, if so, hides the password field and offers the provider buttons. Unknown domains get an identical response shape, so the login screen never reveals whether an account or organisation exists.

Passkeys (passwordless sign-in)

Users who sign in with a password can register passkeys and then sign in without one. A passkey is a WebAuthn credential held by the device or password manager — Touch ID / Face ID, Windows Hello, a hardware security key, or a synced passkey from 1Password, iCloud Keychain or similar. Nothing secret is sent to WatchTower15, so a passkey cannot be phished or replayed.

• Personal, not organisational. A passkey belongs to the user, like a contact method. It works across every organisation that user is a member of.
• Multiple passkeys per account, each with a name you choose (MacBook, YubiKey), so a lost device is revoked without locking you out.
• Manage them in your profile: register, rename, or delete. WatchTower15 records when each was last used.
• Sign in by choosing the passkey option on the login screen — no password and no email round-trip.

Not available to SSO-enforced users

If your organisation has disabled password login, your identity provider is the authority on who you are, and passkey registration is unavailable. Use the provider’s own second factor instead.

Passkey sign-ins are recorded in the audit trail with the method passkey, alongside password and SSO logins.

Sessions

You stay signed in across tabs and browser restarts. A session ends after 24 hours without use, and after 30 days at most; sign in again to continue. Signing out ends the session in every tab.

For SSO-managed users — those on a verified domain of an organisation that has disabled password login — WatchTower15 issues a short 8-hour session instead, so access tracks the working day and re-auth against your IdP happens regularly.

When a session ends, the sign-in page says the session has expired. After an expired session, signing in again returns you to the page you were on.

Linking accounts

A user can link both a Google and a Microsoft identity to the same WatchTower15 account; whichever they use, they land in the same account. Linking happens automatically on first successful SSO sign-in for a matched user.

Not included (and honestly so)

To set expectations clearly, the following are not part of SSO today:

• SAML 2.0 and generic per-organisation enterprise OIDC connections (Okta, Ping, ADFS, custom IdPs).
• SCIM provisioning / automated deprovisioning.
• Just-in-time / auto-provisioning of new users.
• Attribute / claim mapping and IdP group-to-role sync.

These are roadmap candidates; today’s SSO is Google/Microsoft social login with the domain-verification and enforcement controls above.

Related

• Roles & permissions — what a signed-in user can do.
• Audit trail — SSO logins are recorded with provider and outcome.