Appearance

Single sign-on (SSO) ​

Connect LakeSail to your existing identity provider so members sign in with their work credentials. LakeSail speaks OIDC; any provider that does (Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak, etc.) is supported.

There are two setup paths:

  • Auto-setup — works for providers that support OIDC Dynamic Client Registration (RFC 7591). Paste a base URL and LakeSail registers itself as a client.
  • Manual — works for any OIDC provider. You create the client in your IdP yourself and paste the issuer, client ID, and client secret into LakeSail.

Prerequisites ​

  • An organization admin role.
  • An OIDC-compatible identity provider you can administer.

Auto-setup (DCR) ​

  1. Open Settings → Identity Providers and click Add provider.
  2. Choose Auto-setup.
  3. Fill in:
    • Name — display name for this provider (e.g. Company SSO). Up to 255 characters.
    • Provider URL — the OIDC issuer URL, fully qualified with scheme (e.g. https://example.okta.com).
  4. Click Set up.

LakeSail discovers the OIDC configuration from the provider's .well-known/openid-configuration endpoint and registers itself as a client via Dynamic Client Registration. If your provider doesn't support DCR, you'll see an error — fall back to manual setup below.

Manual setup ​

  1. In your IdP, create an OIDC application for LakeSail.
  2. Note the issuer URL, client ID, and client secret (or skip the secret if you're using PKCE).
  3. In LakeSail, open Settings → Identity Providers and click Add provider.
  4. Choose Manual setup and pick the Provider type from the catalog (Okta, Entra ID, Google, generic OIDC, etc.).
  5. Fill in:
    • Name — display name.
    • Issuer — the OIDC issuer URL.
    • Client ID — from your IdP.
    • Client secret — from your IdP. Optional for public clients using PKCE.
    • Scopes — the OAuth scopes to request. Minimum is usually openid email profile.
  6. Click Save.

Test the connection ​

After saving, click Test connection on the provider's detail page. LakeSail walks the OIDC discovery endpoint and verifies the client credentials.

If the test passes, members can sign in via the provider's button on the LakeSail login page.

Sign-in flow ​

Once a provider is configured:

  1. A user clicks Sign in with [provider name] on the LakeSail login page.
  2. They're redirected to the IdP, authenticate, and come back with a token.
  3. If they're a known member of an organization that uses this provider, they land in that org. If their email matches an existing pending invitation, the invitation is accepted automatically.
  4. If neither, signup behavior depends on the provider's configuration.

Rotate secrets ​

If a client secret leaks or you want to rotate on a schedule:

  1. Open the provider's detail page.
  2. Click Rotate secret.
  3. Paste the new client secret from your IdP.

The new secret takes effect immediately; the previous one is invalidated.

Provider types ​

LakeSail's catalog lists supported provider types via ListIdentityProviderTypes. Each type carries:

  • A display name and capabilities (which OIDC features are supported).
  • An enabled and visible flag controlling whether org admins can pick it.

Generic OIDC works as a fallback for any compliant provider not in the typed list.

Group claims and role mapping ​

If your IdP includes group claims in the ID token (most do), LakeSail can map them onto org roles or team memberships.

The cleanest pattern: define groups in your IdP that mirror your LakeSail org roles (e.g. lakesail-admins, lakesail-data-eng), let the IdP be the source of truth, and rely on group claims for authorization in LakeSail.

Troubleshooting ​

  • "Auto-setup failed: provider does not support Dynamic Client Registration." — Use manual setup; create the client in your IdP yourself.
  • "Discovery endpoint not reachable." — Confirm the provider URL includes the scheme (https://) and is reachable from the public internet. Internal-only IdPs can't be auto-discovered.
  • Test connection fails with 401 — Wrong client ID or secret. Re-paste from the IdP and try again.
  • Sign-in works but the user lands in the wrong org — A user with an existing membership in another org that shares the same IdP issuer may have routing ambiguity. Have them switch orgs from the user menu.

API reference ​

  • Identity Providers — AutoSetupIdentityProvider, CreateIdentityProvider, RotateIdentityProviderSecret, TestIdentityProviderConnection, and full CRUD.