Single sign-on: Hivelock

Works with your identity provider.

Connect any OpenID Connect provider directly. If your company uses SAML, connect it through Keycloak in a few steps.

What you need

To be an owner of the workspace.
A client in your provider that uses the authorization code flow, is confidential (it has a secret), and allows PKCE.
Control of your email domain's DNS.

Steps in Hivelock

Open Settings, then Single sign-on.
Enter the issuer address, client ID, client secret and email domain, then save. Hivelock reads the provider's published settings and shows a redirect address.
Add that redirect address to the client in your provider.
Add the DNS TXT record shown, then choose Check the record. DNS can take a while.
Sign in once with SSO in a private window, before you change anything else.
Choose who may join. By default, people need an invitation. Turning on Let new people join on first sign-in lets anyone your provider vouches for join as a viewer.
If you want, turn on Require single sign-on.

The secret is encrypted when saved and never shown again. To use a different provider or domain, remove SSO and set it up again. Removing it signs out everyone who came through it.

Keycloak

Create a realm, or use your own. The issuer is https://your-host/realms/your-realm.
Under Clients, create a client of type OpenID Connect.
Turn on Client authentication, and leave only Standard flow on.
Set Valid redirect URIs to the address Hivelock showed. Do not use a wildcard.
On Advanced, set Proof Key for Code Exchange Code Challenge Method to S256.
Copy the secret from Credentials.
Check that each user has Email verified on. For users from LDAP, turn on Trust Email on the federation, or Hivelock will refuse them.

Authentik

Under Applications, then Providers, create an OAuth2/OpenID Provider.
Set Client type to Confidential, and use an explicit-consent or implicit-consent authorization flow.
Add the address Hivelock showed as a strict redirect URI.
Keep the openid, email and profile scopes. Authentik's default email mapping sends email_verified: false, and Hivelock refuses that. If your addresses are managed so that people cannot change them unchecked, create a custom scope mapping with the scope name email that returns True. Use it in place of the default one on this provider.
Create an Application using this provider.
The issuer is https://your-host/application/o/your-application-slug/, with the slash at the end. Copy it exactly from the provider's page.

Other providers

Anything that publishes /.well-known/openid-configuration and signs ID tokens should work. The issuer in that document must equal the address you enter, and email_verified must be the value true, not the text "true".

On-premise providers

A provider on a private network is refused, unless the server's operator adds its host to ALLOWED_PRIVATE_HOSTS. Plain http is allowed only for hosts on that list. This cannot be used in hosted mode, so a hosted workspace needs a provider reachable from the internet.

SAML through Keycloak

In Keycloak, add your SAML provider under Identity providers.
Connect Hivelock to Keycloak with OpenID Connect, as above.

Keycloak connects to your SAML provider, and Hivelock connects to Keycloak with OpenID Connect. Your people sign in with the accounts they already use.

Rules Hivelock enforces

A provider cannot be used until its domain is proved by DNS, and a proved domain belongs to one workspace.
A sign-in needs email_verified: true and an address in exactly that domain. Subdomains do not count.
An existing account is linked only under those same conditions. In hosted mode, a password on an account whose address was never confirmed is removed before linking, because whoever set it may not own the address.
State, PKCE and a nonce are checked on every sign-in, along with the ID token's signature, issuer and audience.
People arrive only through an invitation, or the join setting.
Signing in with SSO skips Hivelock's own two-step verification, because your provider handles it. So set up a second step in your provider. The same person signing in with a password still needs Hivelock's.
An SSO session reaches its own workspace and nothing else. It cannot change account settings, create workspaces, or act as the platform administrator.

When SSO is required

Password sessions cannot reach the workspace, including through the people screens.

If your provider is down, an owner signed in with password and two-step verification can still get in. They give a reason of at least 10 characters. Access lasts one hour for that one session, and goes in the audit log as sso.break_glass_used.

In hosted mode, if the plan no longer includes SSO, the requirement stops applying, so nobody is locked out.

Audit log

These events are recorded: sso.configured, sso.changed, sso.domain_verified, sso.removed, sso.signed_in, sso.sign_in_refused and sso.break_glass_used.

What the sign-in page reveals

Someone who types an address sees whether it goes to an identity provider, and that provider's address. This cannot be avoided, because the browser has to go there. Hivelock shows no workspace or company name, gives the same answer for an unknown domain as for an unproved one, and limits how fast anyone can ask.

The DNS record is checked once, when the domain is proved, so it can be removed afterwards. If you sell a domain, remove SSO first.

Checked against the code on 6 November 2026.