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

# SSO deployment requirements (BYOC)

> Configure the Console callback, browser-reachable Auth route, Identity route, and tenant resolution for SSO in BYOC.

This page tells a BYOC operator what to configure before an administrator enables [single sign-on](/en/platform/access-manager/features/sso/overview).

<Note>
  This page applies to BYOC deployments only. On Lerian Cloud, Lerian operates this configuration for you.
</Note>

## Set one callback URL

***

Set `PLUGIN_AUTH_SSO_CALLBACK_URL` on both the Auth and Identity services. Use the exact public Console callback URL:

```text theme={null}
https://console.example.com/signin/sso/callback
```

Auth sends this URL to the identity provider. Identity includes it in the allowed redirect configuration.

<Warning>
  Use the same absolute URL in Auth, Identity, the Console, and the identity-provider application. A scheme, host, or path mismatch makes the authorization-code exchange fail.
</Warning>

## Configure Console routes

***

The Console needs these routes:

| Variable                               | Purpose                                                  |
| -------------------------------------- | -------------------------------------------------------- |
| `PLUGIN_AUTH_BASE_PATH`                | Server-to-server Auth API base URL, including `/v1`.     |
| `PLUGIN_AUTH_PUBLIC_BASE_PATH`         | Browser-reachable Auth API base URL, including `/v1`.    |
| `PLUGIN_IDENTITY_BASE_PATH`            | Server-to-server Identity API base URL, including `/v1`. |
| `NEXT_PUBLIC_PLUGIN_AUTH_ENABLED=true` | Enables Access Manager authentication in the Console.    |

Set `PLUGIN_AUTH_PUBLIC_BASE_PATH` to an HTTPS address that the user's browser can reach. The browser follows the redirect from the SSO start operation directly.

With the Product Console Helm chart, set the server-to-server routes in `configmap` and the browser-facing route in `extraEnvVars`:

```yaml theme={null}
product-console:
  configmap:
    PLUGIN_AUTH_BASE_PATH: http://plugin-access-manager-auth.plugin-access-manager.svc.cluster.local:4000/v1
    PLUGIN_IDENTITY_BASE_PATH: http://plugin-access-manager-identity.plugin-access-manager.svc.cluster.local:4001/v1
  extraEnvVars:
    PLUGIN_AUTH_PUBLIC_BASE_PATH: https://auth.example.com/v1
```

<Warning>
  Do not place `PLUGIN_AUTH_PUBLIC_BASE_PATH` under `configmap`. The chart accepts that key but does not render it. Use `extraEnvVars` so the Console receives the value.
</Warning>

The public and server-to-server Auth URLs can point to the same address. In Kubernetes, use the internal service route for server-to-server calls and the public ingress for browser redirects.

## Configure tenant resolution

***

Choose one tenant model.

### Multi-tenant

Set `MULTI_TENANT_ENABLED=true`. Configure each tenant organization with a tag using the `domain:` prefix, such as `domain:example.com`, that Auth must match to user email domains.

Do not set a fixed SSO organization in multi-tenant mode.

### Single-tenant BYOC

Set `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` when every SSO request belongs to one fixed organization. Auth then uses that organization before sign-in instead of resolving an organization from a tag with the `domain:` prefix, such as `domain:example.com`.

<Warning>
  Do not combine `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` with `MULTI_TENANT_ENABLED=true`. Auth rejects this configuration at startup.
</Warning>

## Expose Auth to the browser

***

The browser must reach the Auth SSO start route over HTTPS. Configure a public ingress for Auth and allow the Console origin according to your deployment's cross-origin policy.

Identity can remain on a server-to-server route when administrators manage it only through the Console.

## Configure the identity provider

***

In the provider application:

1. Register the exact Console callback URL.
2. Allow the OpenID Connect scopes required to return the user's identity and email.
3. Issue a client ID and client secret for the tenant.
4. Make the issuer and endpoints reachable from the Access Manager services.

For a Custom OpenID Connect provider, use an issuer that publishes valid discovery metadata. API integrations can instead supply the complete authorization, token, and user-info endpoint set.

## Validate the deployment

***

<Steps>
  <Step title="Open the Single Sign-On tab">
    Make sure the Console can read the current provider state from Identity.
  </Step>

  <Step title="Run provider preflight">
    Test the candidate configuration without saving it. Fix every required failure.
  </Step>

  <Step title="Register the callback URL">
    Compare the provider registration with `PLUGIN_AUTH_SSO_CALLBACK_URL` character by character.
  </Step>

  <Step title="Save the provider">
    Keep password login available during the first test.
  </Step>

  <Step title="Test from a private browser session">
    Enter a tenant email, complete provider sign-in, and make sure the browser returns to the Console.
  </Step>

  <Step title="Test tenant isolation">
    Try an email that does not belong to the tenant. Make sure Auth does not complete the login or reveal tenant details.
  </Step>

  <Step title="Test MFA continuation">
    Sign in with an MFA-enabled user and make sure the Console opens the MFA verification step after SSO.
  </Step>
</Steps>

## Related pages

***

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