Single sign-on (SSO)

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.

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.

Sessions

Standard sessions are long-lived. 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.

Linking accounts

A user can link both a Google and a Microsoft identity to the same WatchTower 15 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.