Skip to main content
LILT platform customers can use Single Sign-On (SSO) to sign in using their organization’s identity provider. SSO simplifies account management and reduces password fatigue. Note: User accounts must exist in LILT before SSO authentication, unless auto-provisioning is configured (see SAML Setup section).

Google SSO

LILT platform users can sign in using their Google account. After receiving an invitation from your organization, you can create an account using Google Sign-On. If you have an existing LILT account with traditional username/password authentication, you can access it using Google Sign-On with a matching email address. Both sign-in methods work interchangeably.

OpenID Connect

OpenID SSO for platform customers is coming in 2025. This feature will enable sign-in through your organization’s SSO using OpenID Connect (OIDC). OpenID Connect is an authentication protocol built on OAuth 2.0 (IETF RFC 6749 and 6750). It provides a standardized way to verify user identity through an Authorization Server and obtain user profile information. OIDC works with many identity providers including Amazon, Microsoft, and Okta.

Microsoft SSO

LILT supports Microsoft authentication for platform customers. Organizations using Active Directory or Azure credentials can use their existing SSO for LILT. To set up Microsoft SSO, a user from your organization needs to:
  1. Log into LILT.com using Microsoft SSO
  2. Complete the consent page
After setup, the SSO app appears under Enterprise applications in your Azure Active Directory (AD) or Azure Entra ID, where you can configure access controls.

Restricting Access

To limit access to specific users:
  1. Click on the LILT app in Enterprise applications and navigate to Manage > Properties
  2. Set Assignment required to Yes
  3. Add users under Manage > Users and Groups
    • Grant access to entire roles, or
    • Add individual users

SAML Setup

To set up a SAML connection with LILT, your organization needs to engage with your LILT customer team. The setup process involves: LILT Actions
  • LILT creates a new organization configuration with a specific identifier (for example: customer:okta)
    • You can choose any name in place of customer:okta. This acts as a verification piece to ensure you’re connecting to the correct configuration.
Customer Actions
  • Set up SAML configuration on your organization’s side and provide the following to LILT:
    1. The sign-on URL for your application
    2. The entity ID for your application
    3. The metadata file for your application
    4. The certificate for your application
  • New user accounts will be provisioned automatically through just-in-time provisioning when users first log in through SAML
  • Configure two custom claims in your organization’s identity provider:

Required Claims for JIT Provisioning

Both of the following claims are required for automatic user provisioning:
  • lilt_api - Your organization’s API key for organization identification
    • This claim is only required for new users being provisioned through JIT. Existing LILT users can authenticate via SSO without this claim.
    • To find your API key:
      1. Log into lilt.com using a non-SSO admin account
      2. Click the gear icon in the lower left corner
      3. Navigate to the API tab
      4. Copy your API key value
    • Warning: Do not log into your admin account via SSO, as this will convert it to SSO-only and you will lose access via the regular login page.
  • lilt_role - The user’s role for permissions within LILT
    • This value must exactly match an existing role name in LILT (for example: Administrator, Manager, or your organization’s standard access role)
    • This can be configured as either:
      • An individual user attribute in your IdP, or
      • A custom group claim (recommended if most users should have the same role)
    • Important: This attribute will override any manual role changes in LILT whenever the user logs in via SSO

Technical Configuration Details

When setting up your SAML claims, ensure:
  • The emailaddress claim should not have a namespace value configured
  • LILT uses email addresses as usernames in the system
  • If your IdP’s user.mail attribute is not consistently populated, you can use user.userprincipalname instead (provided it’s formatted as an email address)
  • The lilt_role attribute value is case-sensitive and must exactly match a role that exists in your LILT organization
  • We recommend a phased rollout approach, starting with your admin and 5 test users before migrating all users to the new SSO experience

OpenID Connect (OIDC) Setup

LILT is expanding SSO support to include OpenID Connect (OIDC) in addition to SAML. This provides more flexibility for organizations using different identity providers. Note: LILT currently supports SAML configuration. OIDC support is being added and will be available soon.

Troubleshooting

JIT Provisioning Is Not Working

If new users cannot log in or are not being automatically provisioned:
  1. Verify both required claims are configured in your IdP:
    • lilt_api must contain your organization’s API key
    • lilt_role must contain a value that exactly matches a role name in LILT
  2. Check for common configuration issues:
    • The emailaddress claim should not have a namespace configured
    • The lilt_role value is case-sensitive and must match exactly
    • Ensure users are accessing the SSO login at /signin2, not the regular login at /signin
  3. Confirm existing vs. new user behavior:
    • Existing LILT users can authenticate via SSO even without the lilt_api claim
    • New users require both lilt_api and lilt_role claims for JIT provisioning

Users Are Locked Out After SSO Setup

If admin users lose access to their accounts:
  • Admin accounts that log in via SSO are automatically converted to SSO-only
  • Once converted, these accounts can only access LILT through /signin2 (SSO), not /signin (regular login)
  • To avoid this, maintain a separate non-SSO admin account for configuration purposes

Frequently Asked Questions

Is SCIM supported? Currently, SCIM is not supported. Auto-provisioning is handled through the two custom claims/attributes (lilt_api and lilt_role) listed in the SAML configuration section. If JIT provisioning is not working:
  • Verify both claims are present in your SAML configuration
  • Confirm the lilt_role value exactly matches an existing role in LILT
  • Ensure the lilt_api contains your organization’s valid API key
Is SSO a global setting or per user/group? SSO is configured per user. The LILT platform supports:
  • Regular logins via /signin
  • SSO logins via /signin2
If a user is configured for SSO and attempts to log in through /signin2, then tries to log in as a regular user, the system will deny entry and require SSO login. For organization-wide SSO implementation, auto-provisioning works as follows:
  • If a user doesn’t exist in the LILT database, they’ll be automatically added when they first log in via SSO
  • The user’s SAML assertion must include the lilt_api claim with your organization’s API key (to identify which organization to add them to)
  • The user’s SAML assertion must include the lilt_role claim with a value that exactly matches an existing role in LILT (to assign appropriate permissions)
  • If either claim is missing or incorrectly configured, JIT provisioning will fail
  • Once configured this way, users can only log in via /signin2 (SSO), not via /signin (regular login)
  • Your organization won’t need to manually add users to the LILT system
Does LILT support multiple Azure app connections for SSO for a single domain? This capability depends on your specific Azure configuration. Each implementation may have unique requirements. Please contact your LILT customer team for guidance on your specific Azure setup.
I