> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Single Sign-On (SSO)

> Configure and enforce SSO for your organization using OIDC or SAML 2.0 identity providers.

Single Sign-On (SSO) lets your team sign in to Tensorlake through your company's identity provider (IdP). Once configured, members authenticate with your IdP instead of managing separate Tensorlake credentials.

## Prerequisites

* You must be an [organization admin](/platform/access-control#organization-admin).
* SSO access must be enabled for your organization. If you don't have access, request it from the SSO settings page in the dashboard.

## Setup

<Steps>
  <Step title="Configure your SSO provider">
    Navigate to **Organization Settings > SSO** and click **Configure SSO Connection**.

    Tensorlake supports two protocols:

    * **OIDC (OpenID Connect)** — recommended for providers like Google Workspace, Okta, and Auth0.
    * **SAML 2.0** — supported for providers like Azure AD (Entra ID), OneLogin, and other SAML-compatible IdPs.

    Provide the following details:

    | Field                      | Description                                                                                                     |
    | -------------------------- | --------------------------------------------------------------------------------------------------------------- |
    | **Domain**                 | Your organization's email domain (e.g. `yourcompany.com`). Users with this domain will be directed to your IdP. |
    | **Issuer URL**             | The issuer or entity ID from your IdP.                                                                          |
    | **Client ID**              | The application/client ID assigned by your IdP.                                                                 |
    | **Client Secret**          | The client secret from your IdP (OIDC only).                                                                    |
    | **Authorization Endpoint** | The URL where users are sent to authenticate (OIDC).                                                            |
    | **Token Endpoint**         | The URL used to exchange authorization codes for tokens (OIDC).                                                 |
    | **ACS URL / SSO URL**      | The Assertion Consumer Service URL (SAML). Provided by Tensorlake.                                              |
    | **Certificate**            | The X.509 signing certificate from your IdP (SAML).                                                             |

    **Attribute mapping:** Ensure your IdP sends at minimum the user's email address. Name attributes (first name, last name) are recommended for a complete profile.
  </Step>

  <Step title="Test the SSO connection">
    After saving your configuration, test the connection by performing a test login.

    1. Click **Test Connection** in the SSO settings.
    2. You will be redirected to your IdP to authenticate.
    3. After successful authentication, you are redirected back to Tensorlake and the provider is marked as **Verified**.

    <Warning>SSO enforcement cannot be enabled until you have completed a successful test login. Enforcing an untested configuration could lock users out of your organization.</Warning>
  </Step>

  <Step title="Enforce SSO (optional)">
    SSO enforcement requires all organization members to sign in through your IdP. When enabled, password-based login is disabled for all members — the only way to sign in is through the IdP.

    To enable enforcement:

    1. Designate at least one organization admin as a **bypass user**. This is required before enforcement can be enabled.
    2. Toggle **Enforce SSO** in the SSO settings.

    **Bypass users** are organization admins who retain password-based login for emergency recovery — for example, if your IdP goes down and you need to access the dashboard to disable enforcement. Only organization admins can be designated as bypass users.

    <Warning>Enabling SSO enforcement invalidates all existing sessions for the organization. All members (except bypass users) will be signed out and must re-authenticate through the IdP.</Warning>

    <Note>Only organization admins can enable or disable SSO enforcement and manage bypass users.</Note>
  </Step>
</Steps>

## How SSO login works

When SSO is configured for your organization, the login flow works as follows:

1. A user enters their email on the Tensorlake login page.
2. Tensorlake checks whether the email domain has an SSO provider configured.
3. If SSO is configured and enforced, the user is redirected to the IdP with an `SSO_REQUIRED` response. Password-based login is not available.
4. If SSO is configured but not enforced, the user can choose to sign in with SSO or with their Tensorlake password.
5. After authenticating with the IdP, the user is redirected back to Tensorlake and signed in.

New users who sign in via SSO on their first login are automatically provisioned with a Tensorlake account. Users who previously signed in with email OTP may need to be [invited to the organization](/platform/access-control#invitation-process) before SSO login will work for them.

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Which identity providers are supported?">
    Tensorlake supports any IdP that implements OIDC or SAML 2.0. Common providers include Okta, Azure AD (Entra ID), Google Workspace, OneLogin, and Auth0.
  </Accordion>

  <Accordion title="Can I configure multiple SSO providers?">
    Each organization supports one SSO provider at a time. If you need to switch providers, update the existing SSO configuration with the new provider's details.
  </Accordion>

  <Accordion title="What happens when I enforce SSO?">
    All members must authenticate through your IdP. Password-based login is disabled for the entire organization, except for designated bypass users.
  </Accordion>

  <Accordion title="Who can be a bypass user?">
    Only organization admins can be designated as bypass users. At least one bypass user is required before SSO enforcement can be enabled. Bypass users retain password-based login solely for emergency recovery, such as disabling enforcement if your IdP becomes unavailable.
  </Accordion>

  <Accordion title="How does SSO enforcement affect API keys?">
    API keys are not affected by SSO enforcement. Existing API keys continue to work regardless of SSO settings. API keys authenticate directly with the Tensorlake API and do not go through the IdP login flow.
  </Accordion>

  <Accordion title="What happens if my IdP goes down while SSO is enforced?">
    If your IdP is unavailable, members will not be able to sign in. A bypass user (org admin with password-based login retained) can sign in and disable enforcement until the IdP is restored.
  </Accordion>

  <Accordion title="Can I test SSO without affecting existing users?">
    Yes. SSO is not enforced until you explicitly enable enforcement. During setup and testing, all users can continue to sign in with their existing credentials.
  </Accordion>

  <Accordion title="Do users need to be re-invited after enabling SSO?">
    No. Existing organization members continue to have access. They will simply be redirected to the IdP on their next login if enforcement is enabled.
  </Accordion>
</AccordionGroup>