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 support@weareoho.com.

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 support@weareoho.com.

Existing password logins. If your team currently signs in with an Oho username and password, decide whether to keep that on once SSO is working. Keeping both on during the changeover is the safe way to roll out; turning password sign-in off afterward makes SSO the only way in.

Keep one break-glass admin

Before you switch password sign-in off, make sure at least one Admin can still get in another way (for example, a retained password login) in case your identity provider is ever unavailable. Locking every route but SSO means an IdP outage locks everyone out, including your admins.

Choose your provider​

Follow the guide for your identity provider: