LakeSentry Single Sign-On (SSO)

LakeSentry supports single sign-on over OpenID Connect (OIDC), so your team signs in through your identity provider instead of passwords or magic links. SAML is not supported.

SSO is available on every plan and is configured per organization by an admin or owner. This page covers how SSO behaves in LakeSentry; for the identity-provider side, see SSO Provider Setup.

Supported providers

Provider preset	Issuer URL
Okta	`https://<your-org>.okta.com/oauth2/default`
Microsoft Entra ID	`https://login.microsoftonline.com/<tenant-id>/v2.0`
Google	`https://accounts.google.com`
Generic OIDC	Any OIDC-compliant issuer — JumpCloud, Auth0, Keycloak, and others

One provider can be enabled per organization at a time.

What your identity provider must support

Authorization Code flow with a confidential client. LakeSentry sends the client secret in the token request body (client_secret_post) and always uses PKCE.
OIDC discovery — the issuer must serve <issuer>/.well-known/openid-configuration over HTTPS.
Scopes openid email profile. An email claim is required; sign-in fails without one.
Verified email — automatic provisioning (auto-approve and invitation acceptance) requires email_verified to be true. If the ID token omits the claim, LakeSentry checks the provider’s userinfo endpoint. Users with unverified emails can still sign in, but only through an access request.

Enabling SSO

Go to Settings > SSO as an admin or owner.

Field	Notes
Provider	One of the presets above.
Display name	Shown on the login button: “Continue with <display name>”.
Issuer URL	Prefilled for Okta, Entra ID, and Google; enter manually for Generic OIDC.
Client ID / Client secret	From the app you registered in your IdP. The secret is encrypted at rest and never displayed again — the field shows “Saved secret preserved”; leave it blank to keep the stored value.
Allowed domains	Optional list of email domains. Empty means any verified email domain is accepted. Matching is case-insensitive.
Redirect URI (read-only)	`https://<tenant-host>/api/v1/auth/oidc/callback` — register this exact URI in your IdP. Use the copy button to avoid typos.

Select the provider preset and confirm the issuer URL.
Paste the client ID and client secret.
Click Test configuration. This validates the issuer’s OIDC discovery metadata — it does not verify the client ID or secret, so a passing test with a wrong secret still fails at login.
Save, then turn on the SSO toggle. Enabling requires a stored client secret.

Once SSO is enabled:

The /login page shows only Continue with <display name>. The password and magic-link forms are hidden.
Admins and users must use SSO. Local authentication — passwords, magic links, and password resets — is disabled for them.
The owner can always sign in with a password or magic link, so you cannot lock yourself out of the tenant. The fallback login page is:

https://<tenant-host>/admin/login

How SSO users get access

Authenticating at the identity provider is not enough — a user also needs a LakeSentry account. Your IdP’s groups and roles are never mapped: the LakeSentry role always comes from an admin approval, an invitation, or the auto-approve policy. Seat limits apply to SSO-created users like any others.

The SSO Access Policy card on Settings > Access controls what happens when an unknown user signs in:

Policy	Behavior
Require approval (default)	The sign-in creates an access request for admin review.
Auto-approve as user	Unknown users with a verified email are provisioned as User immediately. An optional default data scope can be set when visibility filters are available on your plan.

Access requests

The default flow for users without a prior invitation:

The user signs in through the IdP and lands on a “pending approval” page. They are not logged in yet.
An admin opens Settings > Access > SSO Access Requests and approves the request as Admin or User (optionally with a data scope), or denies it. Admins subscribed to system alerts are notified by email.
The user signs in again and lands in the app with the granted role.

Invitations

When you already know who needs access and with what role, invite the user first. When they sign in through the IdP with a matching verified email, LakeSentry accepts the invitation automatically — no access request, no waiting; the invited role and scope apply immediately. Email delivery is not required for this path; the pending invitation just has to exist.

The match is case-insensitive but otherwise exact — aliases and plus-tags are not normalized. On a mismatch the user falls back to an access request. Two edge cases:

Multiple pending invitations for the same email make the sign-in fail; revoke the extras.
An existing local account with the same email goes through admin approval before the SSO identity is linked to it.

Disabling or removing SSO

Turning the toggle off re-enables password and magic-link login for everyone. Users provisioned through SSO have no password yet — they can use magic links, or an admin can set a password for them.
Deleting the configuration removes the provider settings, linked SSO identities, and pending access requests. User accounts and their history remain.

Troubleshooting

Symptom	Likely cause
”This email domain is not allowed” at login	The email’s domain is not in Allowed domains.
User sees the pending page on every sign-in	Their access request has not been approved yet.
Invitation not picked up on SSO login	Email mismatch with the invite, unverified email, or multiple pending invitations for that address.
Test configuration fails	Issuer URL typo, discovery metadata unreachable, or — for Entra ID — a multi-tenant issuer (`/common/`) instead of your tenant-specific one.
Test passes but login fails	Wrong client secret, redirect URI mismatch in the IdP app, or the user is not assigned to the app in the IdP.

Next steps

SSO Provider Setup — Step-by-step guides for Okta, Microsoft Entra ID, Google, and JumpCloud
User Management & Invitations — Invitations, seat limits, and the user lifecycle
Roles & Permissions — What Owner, Admin, and User can do