Skip to main content
SAML / OIDC SSO is available on the Enterprise and Custom plans (see Billing & plans). Orgs that subscribed to a plan that included SSO before the current pricing keep it - grandfathered plans keep their features. Radar Cloud uses WorkOS for SSO. Owners configure their IdP self-serve via the WorkOS Admin Portal - Okta, Azure AD, Google, OneLogin, generic SAML, generic OIDC. On save, WorkOS provisions the connection and notifies the Radar Cloud control plane.

​
Before you start: add your email domain

SSO routing needs your organization’s email domain. Add it under Settings → Organization → General → Auto-join domains (owner-only) before opening SSO setup - e.g. company.com for users signing in as alice@company.com. Your Radar Cloud org settings are the source of truth: the domain is registered as verified for SSO routing automatically, with no DNS record or verification step on your side. Already opened SSO setup before adding a domain (or added one later)? Just add the domain and reopen SSO setup - the domain list re-syncs every time the setup portal opens.

​
Set up SSO

Settings → Organization → SSO (owner-only). Click Open SSO setup (the button reads Manage SSO once a connection already exists):
  1. Radar lazy-creates a WorkOS organization for you (one per Cloud org) and opens the WorkOS Admin Portal in a new tab.
  2. Pick your IdP from the menu. WorkOS will walk you through the IdP-specific steps:
    • For SAML: SAML metadata URL or XML upload, attribute mapping.
    • For OIDC: discovery URL, client ID / secret.
    • For named IdPs (Okta, Azure AD): OAuth-style consent flow that handles the rest.
  3. Save. WorkOS sends a webhook back to the control plane. Once verified, the SSO card flips to Connected and shows the IdP name + last-tested timestamp.
After setup, users from your IdP can sign in via app.radarhq.io/login → “Sign in with SSO” (or whatever the SAML / OIDC discovery flow auto-detects from their domain). New SSO users land in your org with the Default invite role if your domain is allowed; otherwise, an owner needs to invite them explicitly.

​
Domain matching

SSO sign-ins are routed by email domain. The domains come from Auto-join domains under Settings → Organization → General and must match the domain(s) your IdP issues identities for - list every domain your users sign in with. Domains sync to SSO routing each time the setup portal is opened; no DNS verification is required on your side. The list itself is edited on the General page; see Members for how that same list drives domain auto-join. Alongside domain routing, each org has a readable sign-in link that names the organization: app.radarhq.io/login/<handle> (e.g. app.radarhq.io/login/acme-corp). Opening it shows a “Sign in to Acme Corp” page and routes straight to your IdP - the user doesn’t type a domain or pick an organization. Manage it under Settings → Organization → SSO: the sign-in link card shows the link with a Copy button and lets you rename the handle. The handle is generated from your org name and is editable; handles are unique across Radar. The link is a routing hint only - it decides which IdP to send the user to, never who they are. The sign-in callback still derives the real identity from your IdP’s response, so a wrong or stale handle costs a failed sign-in, never access to another org. This link is what makes SSO work for users whose email domain isn’t yours - see SSO for external users.

​
What about JIT / SCIM provisioning?

  • JIT (just-in-time provisioning) - works today. The first time a user signs in via SSO, they’re created as a Cloud user. If domain auto-join is configured, they also land in the org with the default role.
  • SCIM - directory-based user / group sync. Included in the Enterprise and Custom plans; the provisioning endpoints are rolling out. Contact us if you need SCIM enabled for compliance today.

​
Disconnecting SSO

Owners can manage the connection through the WorkOS Admin Portal (the same link the SSO card opens). Removing the connection there stops new SSO sign-ins; existing sessions remain valid until cookie expiry. There’s no “force every user out” button today - if you need to immediately revoke access for someone whose IdP user was disabled, also remove them from Settings → Organization → Members, which cuts their server-side session.

​
Audit

SSO setup and IdP changes show up in the audit log as org.sso.portal_opened; a user’s first SSO sign-in (which provisions their membership) is recorded as org_member.sso_joined. The IdP name and connection ID appear in the metadata.

​
Plan availability

SAML / OIDC SSO is included in the Enterprise and Custom plans. Orgs grandfathered on a legacy plan that included SSO keep it. Google / GitHub sign-in works on every plan, including Free.

​
See also