SSO in Precog

Overview

Single Sign-On (SSO) is an authentication method that allows users to log in to the application using the same credentials they already use for other business systems — such as Okta, Azure AD (Microsoft Entra), or Google Workspace.

It's important to note that SSO applies only to signing in to Precog, not to the authentication methods used to connect your data sources (like Salesforce, Shopify, or Snowflake) or destinations. Those connections each require their own authentication credentials, which are separate from your user login.

SSO is an optional feature for organizations that want centralized identity management and a seamless, secure login experience for their Precog users.

Why It Matters

SSO simplifies how your users access Precog while improving security and compliance.

Centralized login: Your users sign in to Precog with the same company credentials they use elsewhere.

Stronger control: Authentication and password policies are enforced by your identity provider (IdP), not by Precog.

Fewer passwords: Users don't need to remember a separate Precog password.

Simplified management: IT teams can grant or revoke Precog access directly from the company's directory system.

This unified approach makes authentication consistent across your enterprise applications, without affecting how data connections inside Precog are managed.

Supported Protocol

Precog supports SAML 2.0 for enterprise SSO. This is the most widely adopted protocol for enterprise identity federation and is compatible with all major identity providers, including:

  • Okta
  • Azure AD / Microsoft Entra
  • Google Workspace (G Suite)
  • PingIdentity
  • OneLogin
  • Any SAML 2.0-compliant identity provider

How It Works

When SSO is enabled, Precog delegates user login authentication to your organization's identity provider. The IdP becomes the single source of truth for who can access the Precog UI.

Precog supports SP-initiated (Service Provider-initiated) SSO — meaning the login flow always starts from the Precog login page:

  1. The user navigates to the Precog login page and enters their company email address.

  2. Precog identifies the user's organization and redirects the login request to the configured identity provider (e.g., Okta, Azure AD).

  3. The IdP verifies the user's credentials based on your company's security policies (including MFA if configured).

  4. Once verified, the IdP sends a secure SAML assertion back to Precog.

  5. Precog validates the assertion and grants access — no separate password is required or stored by Precog.

This flow uses PKCE (Proof Key for Code Exchange) for additional security, ensuring that authentication tokens cannot be intercepted or replayed.

What About IdP-Initiated SSO?

IdP-initiated SSO — where users click an app icon from the identity provider's portal (e.g., the Okta dashboard) to access Precog directly — is not supported. This is because IdP-initiated flows cannot use PKCE, which Precog requires for secure token exchange.

If your organization wants an IdP-portal experience, there is a recommended workaround: configure a bookmark app in your identity provider that links to Precog's login page. When users click this bookmark, it triggers a secure SP-initiated flow. The user experience is nearly identical — click an icon, arrive at Precog — but the underlying authentication is fully secure.

Most identity providers support bookmark apps:

  • Okta: Add a "Bookmark App" in the Okta admin console
  • Azure AD: Add a "Linked" application in Microsoft Entra
  • Google Workspace: Add a custom SAML app link

When to Use SSO

SSO is most valuable for organizations that:

  • Want to manage Precog user access through their existing identity platform.

  • Require centralized authentication policies (MFA, password rules, session timeouts).

  • Operate in regulated environments with compliance requirements like SOC 2, ISO 27001, or GDPR.

  • Need to simplify onboarding and offboarding by linking Precog access to internal user directories.

For smaller teams or limited-use environments, standard Precog logins may be sufficient. For enterprise setups, SSO provides stronger security and easier administration.

Practical Insight

SSO changes how your team logs in to Precog, not how Precog connects to external data systems. Connections to sources and destinations — such as Salesforce, BigQuery, or Snowflake — each use their own authentication methods (OAuth, API keys, service accounts, etc.).

SSO ensures that only authorized employees can open and manage those connections inside Precog, while the individual integrations still use their own secure credentials to move data.

By separating user access control (SSO) from data connection authentication, Precog provides both enterprise-level identity management and secure, independent data connectivity.