Skip to main content

Set up single sign-on (SSO)

Single sign-on lets your team sign in to Oho with the accounts they already use at work — the same login your organisation manages in Okta, Microsoft Entra ID (Azure AD), Google Workspace, or another identity provider. No separate Oho password to create, remember, or reset.

This page explains what Oho supports, how switching SSO on works, and what changes for your team once it's live. When you're ready to configure it, pick your provider from Choose your provider below.

What you'll end up with

Everyone on your team signing in to Oho with your company login, new accounts created automatically on first sign-in, and access removed the moment someone is off-boarded in your identity provider.

Who this is for​

Turning on SSO is an Admin task with an IT flavour: you configure it yourself in Oho's own settings, using details from your identity provider. You'll need to be an Oho Admin, and you'll need someone who can read (or set up) the app in your Okta, Entra, or Google Workspace. Often that's one person; sometimes the Oho Admin and the IdP administrator are two people working together. A non-technical admin can read What changes for your team to understand the day-to-day effect without touching any of the setup.

What Oho supports​

Oho works with any identity provider that speaks OpenID Connect (OIDC) or SAML 2.0 — which covers all the major ones. Each has a step-by-step guide:

Identity providerProtocolGuide
OktaOIDC or SAMLSet up Okta SSO
Microsoft Entra ID (Azure AD)OIDC or SAMLSet up Entra ID SSO
Google WorkspaceOIDCSet up Google SSO
Any other OIDC or SAML providerOIDC or SAMLSet up any other provider

If your provider supports both protocols, OIDC is the simpler choice and the one we recommend unless your organisation standardises on SAML.

How turning on SSO works​

You configure SSO yourself in Oho, under Settings → Developer → Single Sign-On. The flow is the same whichever provider you use:

  1. Create an app for Oho inside your identity provider (this is what the per-provider guides walk you through).
  2. In Oho, open Settings → Developer → Single Sign-On, turn on Enable Single Sign-On, and choose your protocol — OpenID Connect or SAML 2.0.
  3. Enter the connection details from your provider — for OIDC, a client ID, client secret, and discovery URI; for SAML, your IdP metadata URL. The exact list is in each provider guide.
  4. Test the connection, then Save. Once the test passes, roll it out to your team.

Oho shows you the callback URL to register back in your provider (for SAML, it fills the ACS URL in for you). Copy that value into your IdP app so the two sides match.

Only an Admin sees this screen

Settings → Developer → Single Sign-On is available to Admins. If you can't see it, you're either not an Admin or your plan doesn't include SSO — talk to whoever manages your Oho account. Stuck on the setup itself? Email [email protected].

Technical detail: the callback URL and SP entity ID

Oho uses a single redirect/callback endpoint, built from your Oho URL:

  • OIDC — https://<your-oho-url>/callback/oidc
  • SAML — the Assertion Consumer Service (ACS) URL, https://<your-oho-url>/callback/saml

The SSO settings screen displays these for your tenant (and pre-fills the SAML ACS URL), so register the value shown there rather than typing the pattern from memory. For SAML, the Service Provider entity ID defaults to urn:oho:datahub — use whatever the screen shows, and set the matching Audience URI / Entity ID in your IdP.

What changes for your team​

Signing in. Once SSO is live, people go to your Oho URL and are sent to your identity provider to sign in, then returned to Oho already authenticated. If your IdP enforces MFA, that now applies to Oho too — Oho relies on your provider for the login, so your existing security policies carry across.

New accounts (provisioning). The SSO settings screen has a Automatically create users on first login toggle. Leave it on and the first time someone signs in through SSO, Oho creates their account for them — you don't have to invite them first. Turn it off to keep the door shut until someone is explicitly added in Oho.

Roles and access still apply. SSO decides who can sign in — it does not by itself decide what they can do. Every person is still an Admin, Manager, or Observer, and Managers and Observers are still scoped to the organisations they look after. An Admin sets each person's role and scope in Oho as described in Roles & access, unless you use group mapping (below).

Mapping groups to roles. The SSO screen also has a Sync group membership toggle and a Groups Claim / Groups Attribute field. Turn it on and name the claim (or attribute) your provider uses, and Oho reads the groups a person belongs to on each login — so you can place people automatically from their IdP groups rather than setting each one by hand. How the group names then map to roles depends on your setup; if you're unsure, email [email protected].

Existing password logins. Turning on SSO adds it as a way in; passwords keep working until you say otherwise. Keeping both during the changeover is the safe way to roll out. Once SSO is working, you can require it — see below.

Require SSO and choose who keeps a password​

Go to Settings → Developer → Single Sign-On, in the Sign-in rules section.

  1. Turn on Require SSO to sign in. Passwords stop working for everyone except the people you choose next.
  2. Under Roles that can still use a password, pick the roles that keep a password as a fallback — usually your Super Admins. A role held through a group counts.
  3. Under People who can still use a password, add any emergency-access account that isn't in your identity provider.
  4. Click Save sign-in rules.

Everyone else is sent to your identity provider. If they type their old Oho password, Oho tells them to use SSO instead — and only after the password was right, so the message never reveals which accounts exist. A password reset link can't be used to get around the rule either.

The sign-in page changes to match: it leads with Sign in with SSO, and keeps the password form behind Administrator? Sign in with a password.

Keep one break-glass admin

An identity-provider outage locks out everyone who must use SSO. Keep at least one Admin on the password list. If nobody is on it, only Oho's built-in admin account can still use a password, and the settings page warns you.

The built-in admin account always keeps its password, whatever these rules say — it is the way back in if your identity provider is down. To go straight to the password form, open /login?method=password on your Oho address.

The rules only apply while SSO is on. If SSO is switched off, or stops working because its settings were removed, passwords work for everyone again.

Where people land after signing out​

Under After signing out, send people to, choose:

  • The Oho sign-in page — the default.
  • Straight back to SSO — they go to your identity provider's sign-in. If they're still signed in there, they'll be signed straight back in to Oho, so this suits shared-device setups less well.
  • Another page, such as your intranet — any address starting with https://.

Choose your provider​

Follow the guide for your identity provider: