Skip to main content

SSO with OIDC

With SSO (Single Sign-On), your users sign in to RuleForge using the same credentials they already use for the rest of their work — Google Workspace, Microsoft Entra ID (formerly Azure AD), Okta, or any provider that speaks OIDC.

Why use it​

  • Fewer passwords: the team signs in with the login they already know.
  • Simpler offboarding: when a user leaves, RuleForge access is cut along with corporate access.
  • Corporate audit: the identity provider keeps the consolidated record of who signed in where and when.
  • Central policies: MFA, conditional access, geolocation restrictions, and other company policies apply to RuleForge as well.

Before you start​

To enable SSO, you'll need, on your identity provider:

  • to create an OIDC application/integration for RuleForge;
  • the callback URL that RuleForge will display on the configuration screen;
  • a Client ID and Client Secret generated by the provider.

If you don't have access to create that application on the provider, talk to your company's identity lead.

Register a provider​

  1. Open Settings → Identity → Providers.
  2. Click New provider.
  3. Choose OIDC.
  4. Give it a name (for example, "Google Workspace" or "Corporate Okta").
  5. Fill in the fields on the screen with the values generated on your provider.
  6. Select the email domains allowed to use this provider (for example, @mycompany.com).
  7. Optionally, configure group-to-role mapping so a user in a specific IdP group automatically gets a determined role in the organization.
  8. Save as draft.

Validate and test before activating​

RuleForge separates three states: draft, validated, and active. Before activating:

  1. Click Validate configuration — the product checks the provider is responding correctly, without starting a real login.
  2. If it passes, click Test login flow — here a real user (you) signs in through the provider. This confirms the full path works.
  3. Once everything is confirmed, click Activate.

These steps prevent a bad configuration from locking everyone out.

How the user signs in​

Once active:

  1. On the login screen, the user enters their corporate email.
  2. RuleForge automatically detects that domain uses SSO.
  3. The user is redirected to the provider.
  4. After login, they come back to RuleForge — and if they were trying to open a specific page, they go straight there.

Automatic account creation​

If your organization allows it, users signing in via SSO for the first time get their account created automatically in RuleForge, with the role you configured. This removes the "create user, send invitation" manual step.

To also automate deactivation when someone leaves, see SCIM.

Important notes​

  • Configuration can only be activated after passing validation — this is intentional.
  • You can deactivate the provider at any time without deleting the configuration.
  • SAML is available in the interface as preview — don't use it in production yet. For production, use OIDC.
  • In more complex corporate scenarios (multiple providers, advanced claim mapping), you may need extra support from your identity team.

Common issues​

Configuration validation fails​

On your provider, review whether the OIDC application is published, whether Client ID and Client Secret are correct, and whether the callback URL matches the one RuleForge shows on screen.

Login starts but the user can't get in​

The provider probably isn't sending the expected information (for example, the user's group, or email). Review the application permissions on the provider and the mapping configured in RuleForge.

"My email isn't recognized for SSO"​

Confirm the email domain was added to the OIDC provider and that the provider is active.