0

SSO with custom domains

Setting up SSO to redirect to the correct domain

If custom domains have been set up for a Private Cloud, a specific configuration is required to allow for the redirect during the authentication to point back to the correct domain from which it was initiated.

User steps

Step 1 - DNS (both protocols)

Add the CNAME at your DNS provider pointing the custom domain at your Private Cloud.

Step 2 - Private Cloud portal (both protocols)

Create the domain and confirm it reaches COMPLETED.

Any other status means it isn't trusted. You won't get an error — logins simply return to the main domain instead. FAILED → fix the CNAME first, then recreate; recreating without the CNAME in place will fail again.

The private cloud must be restarted after a domain reaches COMPLETED. The trusted-domain list is read from one of the Ninox backend services once at startup and cached for the life of the process, so a domain that completes while the instance is running is not recognised until it restarts. Until then SSO keeps returning users to the main domain, with nothing in the UI to explain why.

Step 3 - Identity provider

OIDC - mandatory, or login fails outright

Register the callback for every domain, including the main one:

https://pc1.ninoxdb.com/ums/oidc/callback ← main domain https://app.customer.com/ums/oidc/callback ← each custom domain

The format must match exactly — the part most likely to be missed:

✅ ❌

https://app.customer.com/ums/oidc/callback

trailing slash: …/callback/

lowercase host

https://APP.customer.com/…

no port

https://app.customer.com:443/…

Providers compare character by character and there are no wildcards (RFC 6749 §3.1.2.3). A mismatch doesn't fall back — the provider shows an error page and never returns the user to Ninox, so Ninox cannot recover from it.

SAML

Allow https://<custom-domain>/ums/saml/consume as an ACS URL. In Okta this is Other Requestable SSO URLs for SP-initiated SSO; alternatively, with Signed Requests enabled, Okta can use the ACS URL from the signed AuthnRequest.

Step 4 - Ninox Settings (OIDC only)

In Configuration → Authentication → OpenID, the Redirect URI field takes exactly one value. Enter the main domain's callback:

https://pc1.ninoxdb.com/ums/oidc/callback

Not a custom domain, and not a comma-separated list — the field now rejects commas.

This field is only a fallback, used when the feature is off or a request arrives on an unrecognised domain. Put a custom domain here and, with the feature off, every login gets sent to that custom domain.

SAML has no equivalent field — its ACS URL is always derived.

Ninox Steps

Once the user steps have been completed, a specific feature flag called "SsoCustomDomainRedirect must be enabled by us. Please contact support@ninox.com and mention this feature flag in combination with the Private Cloud(s) for which it needs to be activated.

IMPORTANT: Register at the IdP before the flag is enabled. If the flag is on but the provider is not updated a wrong-domain annoyance turns into a failed login.

If something goes wrong

Symptom Cause

Login completes but lands on the main domain

Domain not COMPLETED, instance not restarted since it completed, or the flag isn't on

Error page at the provider, never returns to Ninox

Callback not registered, or registered in a different format

OIDC: "Something went wrong / we can't log you in", landing on the main domain

Login started on a custom domain that isn't trusted yet. OIDC's login state is tied to the domain it started on, so it can't complete on a different one

SAML: logs in fine but on the main domain

Same cause — SAML degrades gracefully where OIDC fails

Cannot save the OIDC settings

More than one Redirect URI entered

Reply

null