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

# Single Sign-On (SSO)

Setting up SSO for the Maverics Console enables users in your organization to log in using your enterprise identity provider. Once SSO is configured and a domain is enabled, all users with that email domain must use the Enterprise SSO login option. New users must be invited to the organization by an organization owner.

## Prerequisites

* **Organization owner role** -- You must be an owner of the organization to configure SSO settings.
* **Identity provider administrative access** -- You need admin access to create and configure an OIDC application in your identity provider.
* **Required claims** -- Your identity provider must return `email`, `given_name`, and `family_name` claims.
* **User assignment** -- Users must be assigned to the application in your identity provider.
* **DNS administrative access** -- You need admin access to your domain's DNS settings for domain verification.

## Configure OIDC Connection

The Maverics Console supports an OIDC connection with any identity provider that returns the required claims (`email`, `given_name`, `family_name`).

**1. Enable SSO for your organization**

Click your profile in the upper-right corner of the Console, then click **Organizations**. Select the organization you want to configure. In the **Organization Settings** card, click **Edit** to open the settings dialog. Toggle **Enable Single Sign-On (SSO)** to on. An SSO Configuration section appears on the organization page.

**2. Configure your identity provider**

Create an OIDC application in your identity provider and collect the required connection details.

**Google**

1. In Google Cloud Console, go to **APIs & Services** > **Credentials**.
2. Click **Create Credentials** > **OAuth client ID**.
3. Select **Web application** as the application type.
4. Complete the setup. You will add the redirect URI in a later step.
5. The Issuer URL for Google is:
   ```
   https://accounts.google.com
   ```
6. From the credentials page, copy the **Client ID** and **Client Secret**.

**Okta**

1. In Okta, go to **Applications** and click **Create App Integration**.
2. Select **OIDC - OpenID Connect** as the sign-in method and **Web Application** as the application type.
3. Complete the application setup. You will add the redirect URI in a later step.
4. Note the **Issuer URL** for your Okta tenant. The format is:
   ```
   https://{yourOktaDomain}.okta.com
   ```
5. From the application's **Client Credentials** section, copy the **Client ID** and **Client Secret**.

**Entra ID**

1. In the Azure portal, go to **Microsoft Entra ID** and select **App registrations** under Manage.
2. Click **New registration** and complete the registration form. You will add the redirect URI in a later step.
3. From the application's **Overview** page, copy the **Application (client) ID** and **Directory (tenant) ID**. The Issuer URL format is:
   ```
   https://login.microsoftonline.com/{yourTenantId}/v2.0
   ```
4. Go to **Certificates & secrets** under Manage and create a new client secret. Copy the secret value.
5. Go to **Token configuration** under Manage. Click **Add optional claim**, select **ID** as the token type, and add the following claims: `email`, `given_name`, `family_name`.
6. Go to **API permissions** under Manage. Ensure **User.Read** under Microsoft Graph is listed. If it is not present, click **Add a permission**, select **Microsoft Graph**, choose **Delegated permissions**, and add **User.Read**. Grant admin consent if required.

**3. Enter connection details**

In the **OIDC Configuration** section on the organization page, enter the following values from your identity provider:

* **Issuer URL** -- The OIDC issuer URL for your identity provider. The field includes inline examples showing the expected URL format for Google, Okta, and Microsoft Entra ID.
* **Client ID** -- The client ID of the application you created.
* **Client Secret** -- The client secret of the application you created. Use the show/hide toggle to verify the value.

Click **Save**.

**4. Configure redirect URI**

After saving, a **Redirect URI** populates in the Console. Copy this URI and add it to your identity provider's application settings:

* **Google** -- Paste the URI in the **Authorized redirect URIs** field in the OAuth client settings.
* **Okta** -- Paste the URI in the **Sign-in redirect URIs** field in the application's Login settings.
* **Entra ID** -- Add the URI under **Redirect URIs** in the application registration's Authentication settings.

> [!NOTE]
>
> The Redirect URI does not populate until SSO settings have been saved in the Console.

## Verify Domains

**1. Add domain**

In the **SSO Domains** section below the OIDC configuration, enter your domain name in the text box and click the **Add** button. If no domains have been configured yet, the section displays "No domains configured".

**2. Copy DNS record**

Copy the **name/host/alias** value that populates after adding the domain.

**3. Add TXT record**

In your DNS provider, add a new TXT record. The record name must be `_strata` and the value must be the string copied from the Console.

**4. Wait for verification**

The Console attempts DNS verification every 30 seconds. Domain verification may take up to 48 hours depending on DNS propagation.

## Enable Domains

After a domain is verified, it appears in the Domains list with a toggle switch. The domain is disabled by default after verification. Enable SSO for the domain by toggling the switch to the **On** position.

You can disable SSO for a domain by toggling the switch back to Off. You can also delete a domain using the trash icon, but if you want to use that domain again in the future you will need to re-enter the details and re-verify it.

> [!WARNING]
>
> When SSO is enabled for a domain, all users with that email domain must use Enterprise SSO login. If SSO is later disabled, those users will be prompted to sign in with another method. Deleting a domain requires re-verification if you want to use it again.

## Troubleshooting

> **Domain does not validate**
>
> Verify that the DNS TXT record is configured correctly. The record name must
> be `_strata`, the record type must be TXT, and the value must be copied
> exactly from the Console. DNS propagation can take up to 48 hours.

> **Internal error during authentication flow**
>
> This error typically indicates an SSO configuration issue. Check the
> following:
>
> * **Issuer URL** -- Verify that you entered the issuer URL, not the
>   `.well-known` URL for the registered application.
> * **Missing claims** -- Verify that your identity provider returns `email`,
>   `given_name`, and `family_name` claims in the ID token.
> * **User permissions** -- Verify that users have permission to use the
>   application in your identity provider.
> * **User profiles** -- Verify that user profiles include all required claim
>   values (`email`, `given_name`, `family_name`).

> **Users cannot sign in after SSO changes**
>
> If SSO was enabled and then disabled, existing SSO users must sign in with
> an alternative method. If SSO was re-enabled, verify that the domain toggle
> is in the On position and that the OIDC connection details (Issuer URL,
> Client ID, Client Secret) are still valid.

## Related Pages

> **[User Management](/reference/console/user-management)**
>
> Manage organization members and roles

> **[Console Overview](/reference/console/overview)**
>
> Console administration overview and capabilities

> **[Break-Glass Procedures](/reference/console/break-glass)**
>
> Emergency procedures when the Console is inaccessible