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 sign-in. When someone joins your organization, they get access to Luma alongside your other tools. Once SSO is enforced, deactivating their account in your identity provider blocks future sign-ins through that account.
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 enforced, 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. Luma doesn’t support SAML.
Your IT team registers Luma as an application in your identity provider, then an organization admin saves the connection details in Luma. The redirect URI (also called the callback or reply URL) is https://luma.com/sso/callback for every provider. Luma signs people in using the email claim in the provider’s ID token; roles are managed separately in Luma.
Set Up and Test Your Connection
You’ll need access to your identity provider’s admin console and to your Luma organization. An existing organization admin can add your IT teammate by email in the organization’s Team tab. Calendar admin access alone doesn’t grant access to organization settings.
- Register the application in your identity provider using the provider-specific settings below.
- In Luma, open your organization’s Settings → Identity, select Set Up SSO, and save the provider, issuer URL, client ID, and client secret. Enter the credentials directly on this page. The connection starts Off, so saving it doesn’t change anyone’s sign-in.
- After saving, email enterprise@luma.com with your organization’s dashboard link and the work email domains you want to use. There’s no need to email us before entering the configuration or send the client secret by email. We verify that your organization controls those domains, add them to the connection, and switch it to Optional for testing.
- Use the test link on the Identity page to sign in with an assigned work account, preferably in a private browser window. In Optional mode, normal email sign-in stays unchanged; use the test link or the configured Okta tile to exercise SSO.
- Once testing passes, reply to confirm you’re ready to enforce SSO. We switch the connection to Enforced, requiring users on the verified email domains to sign in through your provider.
You can edit or remove the connection while it’s Off or Optional. Once SSO is Enforced, the connection is locked; contact our enterprise team to rotate a secret or change providers.
Provisioning and Deprovisioning
Accounts are managed through sign-in itself. Luma doesn’t support SCIM provisioning or Okta Push Groups.
Provisioning: When someone signs in through your identity provider for the first time, Luma creates their account automatically using the verified email address your provider returns. If they already had a Luma account under that email, they keep it—along with their events, calendars, and registrations. There are no invites to send or seats to assign ahead of time; anyone you’ve granted access to the Luma app in your identity provider can sign in.
Deprovisioning: When SSO is enforced, deactivate the user or unassign the Luma app in your identity provider to block future sign-ins. This doesn’t remove their Luma admin roles. Remove organization admins from the organization’s Team tab and calendar admins from the calendar’s Settings → Admins as part of offboarding too.
Roles and permissions: Assign organization and calendar admins within Luma. SSO doesn’t grant an admin role, and Luma doesn’t map groups, roles, or other entitlement claims to permissions. You can use Okta groups to assign access to the Luma app in Okta without sending those groups to Luma.
Okta
Create a custom OIDC - OpenID Connect integration in the Okta Admin Console and choose Web Application. Use these settings for production at luma.com; testing uses the same connection in Optional mode.
| Setting | Value |
|---|---|
| Grant type | Authorization Code. Luma doesn’t need implicit or refresh token grants. |
| Client authentication | Client secret. Luma sends client_id and client_secret in the token request body (client_secret_post). |
| PKCE | Leave Require PKCE as additional verification unchecked. Luma uses the confidential web application flow with a client secret and doesn’t send a PKCE challenge. |
| Sign-in redirect URI | https://luma.com/sso/callback. No additional redirect URIs are needed for Luma’s web or mobile apps. |
| Issuer URL | Your Okta org URL, such as https://your-org.okta.com. A custom authorization server or /oauth2/default issuer isn’t needed. |
| Scopes | Luma requests openid profile email. No groups or custom scopes are needed. |
| Sign-out redirect URI / logout request URL | Leave blank. Luma doesn’t use an OIDC post-logout redirect or Okta Single Logout. |
Assign the app to the users or groups who should be able to sign in. Then save the issuer URL, client ID, and client secret on Luma’s Settings → Identity page and follow the setup and testing steps above.
Launching from the Okta dashboard
Luma supports both starting on Luma and launching from an Okta app tile. To show the tile, set Login initiated by to Either Okta or App, make it visible to users, and choose the OIDC-compliant flow that redirects to the app to initiate login. Set Initiate login URI to https://luma.com/sso/launch. Okta supplies the iss query parameter with your org’s issuer URL. The launch URI starts sign-in; the callback URI receives the response. The Send ID Token directly to app (Okta Simplified) flow isn’t supported.
ID token claims
Luma identifies the user by the ID token’s email claim, which must use a verified domain on your Luma SSO connection. The token must include sub, email, iat, and exp, with the correct iss and aud; name is optional. Use RS256 signing. Okta’s email_verified claim isn’t required, and no group, role, or custom claims are consumed.
Signing out
Luma and Okta have separate sessions. Signing out of one doesn’t automatically sign you out of the other. Leave Single Logout disabled for this integration.
Auth0
Create a Regular Web Application in the Auth0 Dashboard. Your issuer URL is your Auth0 domain, like https://your-tenant.us.auth0.com. Add https://luma.com/sso/callback to the application’s allowed callback URLs, then enter the issuer URL, client ID, and client secret on your organization’s Identity page.
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. Add https://luma.com/sso/callback to the client’s Authorized redirect URIs, then enter the client ID and client secret on your organization’s Identity page.
Microsoft Entra
In the Microsoft Entra admin center, register a new application under App registrations. Add a Web platform redirect URI of https://luma.com/sso/callback, 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. Then enter the issuer URL, client ID, and client secret on your organization’s Identity page.
Getting Started
SSO is available exclusively on Luma Enterprise plans and is configured by organization admins on your Luma organization. Our enterprise team is happy to help your IT team through setup.
If your organization is interested in SSO, contact us at enterprise@luma.com 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.