Skip to content

Single sign-on (SSO)

OpenWatch lets people sign in with an existing identity instead of a local password. Two mechanisms are available: site-wide social login (Google and Microsoft) and per-organisation enterprise SSO over OpenID Connect (OIDC).

Sign-in options at a glance

Option Scope Configured by Typical use
Email + password Per user The user Default local accounts
Google OAuth Site-wide Deployment operator Quick social login
Microsoft / Entra ID OAuth Site-wide Deployment operator Microsoft 365 organisations
Enterprise SSO (OIDC) Per organisation Organisation admin Keycloak, Auth0, Okta, Authentik, and other OIDC providers

New users signing in through any of these are created automatically on first login (just-in-time provisioning), so you do not have to pre-create their accounts.

Google and Microsoft social login

Google and Microsoft login are configured once for the whole deployment. On the hosted SaaS they are available out of the box. When enabled, users see the matching buttons on the sign-in page and can authenticate with their Google or Microsoft account.

Site-wide, not per organisation

Google and Microsoft credentials are set by the deployment operator in the super-admin console. As an organisation admin you do not configure these; you configure enterprise SSO (below).

Enterprise SSO with OpenID Connect

Enterprise SSO connects one organisation to your own OIDC identity provider. Open Admin > SSO to set it up.

What you need from your provider

Create an application (client) in your identity provider and collect:

  • Discovery URL (also called the issuer or well-known configuration URL), for example https://idp.example.com/realms/main/.well-known/openid-configuration.
  • Client ID.
  • Client secret.
  • Scopes (usually openid profile email).

Register OpenWatch's callback URL in your provider as the allowed redirect URI. The exact URL is shown on the SSO configuration page.

Configure it in OpenWatch

  1. Go to Admin > SSO.
  2. Paste the discovery URL, client ID, client secret and scopes.
  3. Save.

The client secret is encrypted at rest

The OIDC client secret is encrypted before storage and only used during the sign-in exchange with your provider.

Enforce SSO for the organisation

You can require members of the organisation to sign in through your identity provider. When SSO enforcement is on, password-based sign-in is refused for that organisation's members and they are routed to your provider instead.

Keep a way in

Before enforcing SSO, confirm the sign-in flow works end to end with a test account. Enforcing SSO with a misconfigured provider can lock members out.

Email verification handling

OpenWatch trusts the email_verified claim from your provider. If your identity provider marks the email as verified, the OpenWatch account is treated as verified and the user is not asked to verify it again.

How members sign in

Once SSO is configured:

  • With social login, members click the Google or Microsoft button on the sign-in page.
  • With enterprise SSO, members enter their email and are redirected to your identity provider; after authenticating there, they return to OpenWatch already signed in.