Skip to main content

Set up any other OIDC or SAML provider

Oho works with any identity provider that supports OpenID Connect (OIDC) or SAML 2.0 — not just Okta, Entra, and Google. Use this guide if your provider is something else (OneLogin, Ping Identity, Auth0, Keycloak, JumpCloud, ADFS, and so on). It's the provider-agnostic companion to Set up SSO — read that first for how SSO configuration works in Oho and what changes for your team.

Who this is for

You'll need administrator access to your identity provider, with rights to create an application (OIDC) or a service-provider connection (SAML). If your provider supports both, OIDC is the simpler choice and the one we recommend.

Register Oho as an application​

In your identity provider, create a new application (the wording varies — "application", "client", "relying party", or "service provider"). Choose a web application with the authorization code flow for OIDC, or a SAML 2.0 service provider for SAML.

When it asks for a redirect, callback, reply, or Assertion Consumer Service (ACS) URL, use the value shown on Oho's SSO settings screen (Settings → Developer → Single Sign-On) — built from your Oho URL:

  • OIDC redirect/callback URL — your Oho URL followed by /callback/oidc
  • SAML ACS URL — your Oho URL followed by /callback/saml

For SAML you'll also set an entity ID / audience to match Oho's SP Entity ID, shown on the same screen (it defaults to urn:oho:datahub).

Register the exact URL Oho shows you

Every provider rejects sign-in if the registered redirect/ACS URL doesn't match exactly. Copy the value from Oho's SSO screen rather than typing the pattern from memory.

Set the user identifier​

Oho identifies people by email. Configure the application so the token or assertion carries the user's email address:

  • OIDC — request the openid, profile, and email scopes. Oho reads the email claim by default.
  • SAML — set the Name ID format to email address, or map an email attribute in the assertion.

Map groups to roles (optional)​

If you want Oho to place people into roles automatically from your provider's groups, configure the application to include group membership:

  • OIDC — add a groups claim to the ID token.
  • SAML — include a groups attribute in the assertion.

In Oho's SSO screen, turn on Sync group membership and set the Groups Claim (OIDC) or Groups Attribute (SAML) to the name your provider uses — see Mapping groups to roles. If you skip it, an Oho Admin assigns each person's role instead.

Enter the details in Oho​

In Oho, go to Settings → Developer → Single Sign-On, turn on Enable Single Sign-On, choose your protocol, and enter:

For OIDC:

  • Client ID
  • Client secret
  • Discovery URI — your provider's .well-known/openid-configuration document

For SAML:

  • IdP metadata URL — the URL to your provider's SAML metadata XML

Then click Test connection and, once it passes, Save.

The client secret is a credential

For OIDC, anyone with the client secret can impersonate the Oho app against your provider. Paste it straight into Oho's SSO screen rather than emailing or ticketing it, and rotate it if it's ever exposed. Oho stores it securely and never shows it again.

Test the first sign-in​

After the connection test passes and you've saved, go to your Oho URL in a private/incognito window, sign in through your provider, and confirm you're returned to Oho signed in.

Common questions​

Which should I choose — OIDC or SAML? OIDC if your provider offers it: fewer moving parts and no metadata XML to keep in sync. Choose SAML if your organisation standardises on it or your provider only supports SAML.

Sign-in fails with a redirect or ACS mismatch. The URL registered in your provider doesn't exactly match the one on Oho's SSO screen. Re-check it against the value shown there.

My provider isn't listed anywhere — is it still supported? If it speaks standard OIDC or SAML 2.0, yes. If you're unsure, email support@weareoho.com with your provider's name and we'll confirm.