> ## 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.

# Single sign-on

> Let users sign in to a Lerian workspace through Google, Microsoft Entra ID, Okta, or another OpenID Connect provider.

Single sign-on (SSO) lets an external identity provider authenticate users for a Lerian workspace. Access Manager resolves the user's tenant, redirects the browser to the provider, and exchanges the provider's authorization code for Lerian access tokens.

SSO applies to user sign-in. Machine-to-machine applications continue to use client credentials.

## Supported providers

***

| Provider                  | Configuration                                                                                                                |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Google**                | OAuth client ID, client secret, and the Lerian callback URL.                                                                 |
| **Microsoft Entra ID**    | OAuth client ID, client secret, and the Lerian callback URL. The API identifies this provider as `AzureAD`.                  |
| **Okta**                  | OAuth client ID, client secret, Okta domain, and the Lerian callback URL.                                                    |
| **Custom OpenID Connect** | Client ID, client secret, optional scopes, the Lerian callback URL, and either an issuer URL or explicit provider endpoints. |

Access Manager supports one active SSO provider per tenant. Configuring another provider replaces the current configuration.

<Note>
  This SSO contract uses OAuth 2.0 and OpenID Connect. It does not configure a SAML provider.
</Note>

## How sign-in works

***

1. The Console asks for the user's email address.
2. Auth resolves the tenant from the email domain using an organization tag with the `domain:` prefix, such as `domain:example.com`, or uses the fixed organization configured by `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` in a single-tenant BYOC deployment. It then returns the available sign-in method.
3. The Console creates an S256 PKCE challenge.
4. Auth redirects the browser to the configured identity provider.
5. The provider authenticates the user and returns an authorization code to the Console callback URL.
6. The Console sends the code, state, and PKCE verifier to Auth.
7. Auth verifies the flow and the returned email identity.
8. Auth returns Lerian access tokens or continues to [MFA verification](/en/platform/access-manager/features/mfa/overview).

Auth verifies that the email returned by the provider belongs to the same tenant that started the flow. It refuses the login when the email is missing or resolves to another tenant.

## Tenant resolution

***

A single-tenant BYOC deployment can use one fixed organization instead. Do not combine fixed-organization SSO with multi-tenancy.

Discovery does not reveal tenant identifiers. An unknown email receives the same general response as a tenant without SSO.

## Password login policy

***

A tenant can allow or disable local password login through the Identity API.

The Console does not expose a separate password-policy control. When you configure the first SSO provider in the Console, password login remains available until the first successful SSO login. Auth then disables local password login for that tenant.

API integrations can set the password policy explicitly when they need a different transition:

* Disable password login immediately after the provider is configured.
* Keep password login available alongside SSO.

<Warning>
  Test SSO before you disable local password login. An invalid client secret, issuer, domain, or callback URL can prevent every user from signing in.
</Warning>

## Configuration validation

***

Run preflight validation before saving a provider. Preflight does not change the tenant configuration.

It checks:

* required fields.
* OpenID Connect discovery when the provider uses an issuer URL.
* explicit endpoint validation when the API supplies authorization, token, and user-info URLs.
* client credentials.
* the callback URL.
* the resolved authorization, token, and user-info endpoints.

Okta cannot always confirm the callback registration through preflight. Register the callback URL in Okta before you enable the provider.

## Next steps

***

<Columns cols={2}>
  <Card title="Configure SSO in the Console" icon="desktop" href="/en/platform/access-manager/features/sso/console">
    Test, save, review, and remove the tenant's provider.
  </Card>

  <Card title="SSO deployment requirements" icon="server" href="/en/platform/access-manager/features/sso/deployment">
    Configure callback URLs, public Auth routing, and tenant resolution.
  </Card>

  <Card title="Multi-factor authentication" icon="shield-halved" href="/en/platform/access-manager/features/mfa/overview">
    Add a second verification step after SSO.
  </Card>
</Columns>