Single Sign-On (SSO)

Single Sign-On (SSO) lets your organization manage access to Luma through your existing identity provider. Instead of creating separate Luma accounts with their own passwords, your team signs in to Luma using the same credentials they use for other work applications.

Why Organizations Use SSO

SSO gives your IT and security teams centralized control over access. When someone joins your organization, they get access to Luma alongside your other tools. When someone leaves, revoking their account in your identity provider immediately removes their Luma access.

You can apply your existing security policies—multi-factor authentication (MFA), password requirements, and access controls. All sign-in events are logged centrally for compliance and audit, giving your security team visibility into who’s accessing Luma.

How It Works

Luma connects to your identity provider using OpenID Connect (OIDC). Once SSO is configured, your team visits Luma and enters their work email. They’re redirected to your provider’s familiar sign-in page, authenticate there, and are immediately signed in to Luma. If they’re already signed in to other work applications, the process is often instant.

Your IT team registers Luma as an application in your identity provider once and shares the connection details with our enterprise team—the issuer URL, client ID, and client secret. We’ll give you the exact redirect URI to register. From then on, all access control happens through your existing system, and Luma signs people in using the verified email address your provider returns.

Okta

Create an OIDC app integration in the Okta Admin Console using the Authorization Code flow (a "Web" application, so it has a client secret). Your issuer URL is your Okta domain, like https://your-org.okta.com. Share the issuer URL, client ID, and client secret with our team, and add the redirect URI we provide.

Auth0

Create a Regular Web Application in the Auth0 Dashboard. Your issuer URL is your Auth0 domain, like https://your-tenant.us.auth0.com. Share the issuer URL, client ID, and client secret with our team, and add the redirect URI we provide to the application’s allowed callback URLs.

Google Workspace

In the Google Cloud Console, create an OAuth 2.0 Client ID of type Web application — not iOS, Android, or Desktop, because Luma signs in through a confidential web flow that uses a client secret. On the OAuth consent screen, set the user type to Internal so only members of your Google Workspace can sign in. Your issuer URL is https://accounts.google.com. Share the client ID and client secret with our team, and add the redirect URI we provide to the client’s Authorized redirect URIs.

Microsoft Entra

In the Microsoft Entra admin center, register a new application under App registrations. Add a Web platform redirect URI using the one we provide, and create a client secret under Certificates & secrets — Luma signs in through a confidential web flow that uses a client secret. Your issuer URL is https://login.microsoftonline.com/{tenant-id}/v2.0, where {tenant-id} is the directory (tenant) ID shown on the app’s overview page. Under Token configuration, add the optional email claim to the ID token — Entra omits it otherwise, and Luma signs people in by email. Share the issuer URL, client ID, and client secret with our team.

Getting Started

SSO is available exclusively on Luma Enterprise plans. Setting it up requires coordination between your IT team and our enterprise team to ensure proper configuration and security.

If your organization is interested in SSO, contact us at [email protected] to learn more about Enterprise plans and begin the setup process. If you use an identity provider that isn’t listed above, reach out anyway—we support any provider that speaks OpenID Connect.