Enterprise SSO

Enterprise SSO connects a Grovs project to your organisation's identity provider over OpenID Connect. Once connected, people on your email domains sign in with the "Continue with your organisation" button instead of a password, an admin can make that the only way in, and SCIM provisioning keeps the member list in step with your directory.

Microsoft Entra ID is the provider this guide walks through. Any OpenID Connect provider with discovery works the same way.

• Set up Microsoft Entra ID — the sign-in side, about 20 minutes.
• SCIM provisioning — automatic joiners and leavers.

Availability

Enterprise SSO is available on:

• Self-hosted deployments — always on.
• SaaS projects on an enterprise plan.

Other projects don't see the section in Settings, and the API answers 403.

How sign-in changes

The login page asks Grovs whether the typed email address belongs to a connected domain, and adapts:

Typed domain	What the page shows
Not connected	Google, Microsoft and password sign-in, as before
Connected, enforcement off	"Continue with your organisation", with the password form behind a link
Connected, enforcement on	"Continue with your organisation" only

A person's first sign-in through the organisation creates their Grovs account and adds them to the project as a member, or as an admin if their token carries the admin role you configured. Someone who already had a Grovs account with that email keeps it: the account is linked to the organisation and their existing roles and links stay.

Requiring single sign-on

With Require single sign-on turned on, every verified domain of the connection becomes SSO-only. Password sign-in, password reset, invitation acceptance, public sign-up and the Google or Microsoft buttons all answer "Sign in with your organisation's SSO" for those addresses, and every existing session on those domains is signed out at the moment you turn it on.

Enforcement follows the email domain, not the project: a person on an enforced domain cannot use a password anywhere in Grovs, even on another project they belong to.

What Grovs verifies

• The ID token is validated against your provider's published keys, with PKCE on every request and only RS256 signatures accepted.
• The token's issuer must match the tenant you configured exactly. A token from any other tenant is refused, which is why the Entra common endpoint is rejected at setup.
• The email in the token must belong to one of the connection's verified domains. Guest accounts from other domains in your tenant are refused.
• On SaaS, a domain is verified with a DNS TXT record you add, and only one project can hold a verified claim on a domain. Self-hosted deployments verify domains on save.

Removing the connection

Removing a connection deletes its configuration and domains and nothing else. Accounts, roles and links are kept, and enforcement ends. People who had a password keep using it; people created through SSO or SCIM use Forgot your password? to set one. If you later add a new connection for the same domains, their first sign-in links them to it, with no duplicate accounts.

Removal is refused while enforcement is on, so that nobody deletes the only way in by accident.

Audit events

Every change is written to the audit log: sso_connection.created, updated, deleted, domain_verified, enforce_enabled with the number of sessions revoked, enforce_disabled, scim_token_rotated, scim_disabled, and user.sso_login for each sign-in. Provisioning writes scim.user.created, updated, deactivated, reactivated and deleted, with the SCIM token as the actor.