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

# Configure SSO in the Console

> Test, save, review, reconfigure, and remove a tenant's single sign-on provider in Lerian Console.

This guide shows how to configure [single sign-on](/en/platform/access-manager/features/sso/overview) from the Security page of Lerian Console.

## Before you start

***

You need permission to read Security settings and identity providers. You also need permission to configure or remove an application provider.

Create an OAuth or OpenID Connect application in your identity provider. Keep its client ID and client secret available.

<Warning>
  Keep local password login available until you complete a successful SSO test. A provider or callback error can prevent users from signing in.
</Warning>

## Open the Single Sign-On tab

***

<Steps>
  <Step title="Open Settings">
    Click the gear icon (<Icon icon="gear" />) in the top navigation bar.
  </Step>

  <Step title="Select Security">
    Select **Security** in the Settings sidebar.
  </Step>

  <Step title="Select Single Sign-On">
    The page opens on the **Single Sign-On** tab. You can also open `/settings/security?tab=sso` directly.
  </Step>
</Steps>

The page shows the active provider when one is configured. It also shows the authorized redirect URI that you must register with the provider.

## Register the callback URL

***

Copy the authorized redirect URI from the Console and add it to the provider application. The Console derives the value from the current browser origin. Confirm that this is the canonical Console URL that your users open. The path ends with:

```text theme={null}
/signin/sso/callback
```

The scheme, host, and path must match exactly. Use HTTPS outside local development.

## Configure a provider

***

<Steps>
  <Step title="Open the configuration form">
    Click **Configure SSO**. If a provider exists, use the reconfigure action instead.
  </Step>

  <Step title="Select the provider type">
    Select Google, Microsoft Entra ID, Okta, or Custom OpenID Connect.
  </Step>

  <Step title="Enter the credentials">
    Enter the client ID and client secret. You must enter the complete secret on every save or reconfiguration.
  </Step>

  <Step title="Enter the provider-specific settings">
    For Okta, enter the Okta domain. For Custom OpenID Connect, enter the issuer URL and optional scopes.
  </Step>

  <Step title="Test the connection">
    Run the connection test before you save.
  </Step>

  <Step title="Review the checks">
    Fix each failed check. Review the discovered authorization, token, and user-info endpoints.
  </Step>

  <Step title="Save the provider">
    Register the callback URL and resolve every required preflight failure before you save. The Console does not block saving when preflight has not passed.
  </Step>
</Steps>

The connection test checks the candidate configuration without changing the active provider.

The Console uses deferred password disablement. Local password login remains available until the first successful SSO login. The Console does not expose an immediate password-policy control.

## Provider-specific settings

***

### Google and Microsoft Entra ID

Enter the client ID and client secret from the provider application. Register the callback URL shown by the Console.

### Okta

Enter the client ID, client secret, and Okta organization domain. Register the callback URL manually in Okta. The Console does not present the callback probe as a reliable Okta check.

### Custom OpenID Connect

Enter an absolute issuer URL. Access Manager uses OpenID Connect discovery to resolve the authorization, token, and user-info endpoints.

Scopes are optional. Enter them as a space-separated list, such as `openid profile email`.

## Review the active provider

***

The provider summary shows its type, display name, and masked client ID. The callback URL appears in the configuration form. Custom OpenID Connect endpoints appear during configuration when they apply. The client secret is write-only and never appears after you save it.

To change the provider, open the reconfiguration form and enter the full credentials again.

## Remove the provider

***

Removing the provider stops new SSO sign-ins for the tenant. Existing sessions continue until they expire or are revoked through the relevant session controls. When Identity removes an active provider, it enables local password login, even if the previous SSO policy disabled it. Removing SSO when no provider is active leaves the current password policy unchanged.

<Warning>
  Make sure an administrator can still use an allowed sign-in method before you remove the provider.
</Warning>

## Test user sign-in

***

<Steps>
  <Step title="Open a private browser session">
    Use a private session so an existing provider session does not hide the login flow.
  </Step>

  <Step title="Enter a tenant email address">
    Enter an email address whose domain belongs to the configured tenant.
  </Step>

  <Step title="Continue with the provider">
    Select the provider if password login is also available. The Console redirects automatically when SSO is the only method.
  </Step>

  <Step title="Complete provider authentication">
    Sign in at the identity provider and return to the Console callback.
  </Step>

  <Step title="Complete MFA if required">
    Finish the second verification step for users who have MFA enabled.
  </Step>
</Steps>

## Related pages

***

<Columns cols={2}>
  <Card title="Single sign-on" icon="right-to-bracket" href="/en/platform/access-manager/features/sso/overview">
    Provider support, tenant resolution, and password policy.
  </Card>

  <Card title="SSO deployment requirements" icon="server" href="/en/platform/access-manager/features/sso/deployment">
    Configure the callback and browser-reachable Auth route.
  </Card>
</Columns>