Skip to main content
This guide is for super admins. It explains how to connect your company identity provider (IdP) so members sign in with your existing corporate login instead of one-time codes. e6data supports two protocols:
  • SAML 2.0 - for IdPs like Okta, OneLogin, Microsoft Entra ID, and Google Workspace SAML apps.
  • OIDC (OpenID Connect) - for IdPs that expose an OIDC discovery document, including Google, Okta, OneLogin, Entra ID, and Amazon Cognito.
Each organization uses one protocol at a time. To switch, delete the existing configuration and create a new one. You must be a super admin to view or change SSO settings (Management → SSO in the left nav).

​
How SSO sign-in works

  1. A member enters their work email.
  2. e6data matches the email domain to your organization (by existing account or a matching auto-join domain) and redirects to your IdP.
  3. The member authenticates at the IdP, which returns a SAML assertion or OIDC token.
  4. If no account exists, one is created automatically (just-in-time) with the Viewer role; otherwise the member signs in.
Just-in-time (JIT) provisioning creates a member’s account on first SSO sign-in with the Viewer role - promote them afterward from Access Control → Users. While SSO is enabled, manual invitations are disabled because the IdP is the source of truth for who can sign in. See Domain auto-join and JIT provisioning.

​
Before you start

  • Super admin access to the SSO page.
  • Admin access to your IdP to create an application.
  • Your organization’s email domain configured for auto-join, so domain routing sends members to the right IdP - see Domain auto-join and JIT provisioning.
e6data exposes service-provider (SP) values to copy into your IdP. You choose the SP Entity ID; the ACS URL, SP Metadata URL, and OIDC Redirect URI are generated and shown on the SSO page once you create the configuration:

​
Set up SAML

  1. Open the SSO page and select the SAML tab.
  2. Under Identity Provider, enter your IdP details: Instead of typing these, use the Metadata section: paste the Metadata XML (recommended - auto-fills entity ID, SSO URL, and certificate) or provide a Metadata URL.
  3. Set Service Provider → SP Entity ID (Audience) to match the audience configured in your IdP. Optionally configure Attribute Mapping (defaults: email, firstName, lastName) and Advanced options (Logout/SLO URL, IdP-initiated SSO, request signing).
  4. Select Create SAML Configuration. Copy the generated ACS URL and SP Metadata URL into your IdP’s SAML app.
  5. Enable the configuration, then test from an incognito window with a test member’s work email.
You can disable a configuration without deleting it - useful while testing.

​
Set up OIDC

  1. Open the SSO page and select the OIDC tab.
  2. In your IdP, create an OAuth/OIDC application (type Web application) and set its authorized redirect URI to e6data’s OIDC callback ({base-url}/api/v1/auth/sso/callback/{orgId}, also shown on the SSO page). Collect the app’s Issuer URL, Client ID, and Client Secret.
  3. On the SSO page, enter: e6data discovers the authorization, token, JWKS, and userinfo endpoints from the issuer’s /.well-known/openid-configuration. Standard scopes (openid profile email) and PKCE are always used.
  4. Select Create OIDC Configuration, confirm the Redirect URI matches your IdP app, Enable, and test from an incognito window.

​
Google

Connect Google as an OIDC provider - there’s no separate Google option. In the Google Cloud Console, create an OAuth 2.0 Client ID (Web application), add e6data’s Redirect URI as an authorized redirect URI, then create an OIDC configuration with issuer https://accounts.google.com and the client ID/secret. e6data recognizes the Google issuer automatically.

​
After SSO is enabled

  • New members are created on first sign-in (JIT) with the Viewer role - promote them from Access Control → Users.
  • Existing members keep their roles; their account links to the IdP identity on next sign-in.
  • Blocked members remain blocked - SSO does not bypass a block.
  • Manual invitations are disabled while SSO is enabled.

​
Troubleshooting

Sign-in failures return to the login page with a reason code: For security, e6data does not log raw assertions or tokens - reproduce failures in an incognito window and note the reason code shown on the login page.

​
See also

Last modified on September 29, 2026