Configuring Single Sign-On (SSO)

Loadster offers SSO with SAML 2 on plans that include it, and a team admin can set it up from the Team page of your Loadster settings. If your plan doesn’t include SSO, contact sales@loadster.com to add it.

This guide covers how to integrate Loadster with your identity provider for Single Sign-On authentication and automatic user provisioning, when it’s supported by your plan.

SSO Overview

Loadster supports two complementary SSO technologies:

SAML 2.0 Authentication - Allows users to log in using their corporate identity provider credentials
SCIM 2.0 User Provisioning - Automatically creates and removes user access as employees join or leave your organization

These can be used together or independently. If you enable SAML without SCIM, user account provisioning and updates will happen “just in time” whenever a user at your organization completes SSO authentication. Enabling SCIM helps keep your organization’s user accounts in sync even if users aren’t signing in to Loadster, and can be helpful in automatically deactivating Loadster accounts for users who leave your organization.

SAML 2.0 Authentication Setup

SAML 2.0 enables your users to authenticate with Loadster using their existing corporate credentials from identity providers like Microsoft Entra ID (Azure AD), Okta, Google Workspace, and others.

Setting Up SSO in Loadster

A team admin sets up SAML under Single Sign-On on the Team page of your Loadster settings:

Copy Loadster’s values. The Single Sign-On section shows the Entity ID, Reply (ACS) URL, Sign-on URL, and Logout URL your identity provider needs. They include a registration ID unique to your team.
Create a SAML app in your identity provider with those values, following the guide for your provider below. Send each person’s email address as the NameID, or as an attribute named emailaddress.
Give Loadster your identity provider’s metadata. Paste its metadata URL, or paste the metadata XML, and save. With a URL, you can have Loadster download the metadata again later, such as after your identity provider rotates its certificate.
Verify your email domains, so your identity provider can sign in the people on them.
Test signing in. Loadster sends you to your identity provider and back, and shows who it signed in. A test doesn’t sign you in to Loadster or change anything for your team.
Turn on single sign-on once a test passes.

If Loadster set up SSO for your team by hand, it keeps working as it is. To manage it yourself instead, choose Switch to an Identity Provider You Manage. That gives you new values to add to your identity provider, and you test the new setup before it replaces the old one.

Microsoft Entra ID Setup

Prerequisites

Admin access to your Microsoft Entra ID (Azure AD) tenant
Permission to create Enterprise Applications in Azure

Create Enterprise Application in Azure

Sign in to the Azure Portal (https://portal.azure.com)
Navigate to: Entra ID → Enterprise Applications → New Application
Select Create your own application
Name it “Loadster” (or your preferred name)
Choose Integrate any other application you don’t find in the gallery (Non-gallery)
Click Create

Configure SAML Single Sign-On

In your new application, go to Single sign-on and select SAML
Click Edit on Basic SAML Configuration and enter the following:

Identifier (Entity ID):
```
https://api.loadster.com/saml2/service-provider-metadata/{REGISTRATION_ID}
```
(Copy the exact value from the Single Sign-On section of your Team settings)

Reply URL (Assertion Consumer Service URL):
```
https://api.loadster.com/login/saml2/sso/{REGISTRATION_ID}
```
(Copy the exact value from the Single Sign-On section of your Team settings)

Sign on URL:
```
https://api.loadster.com/saml2/authenticate/{REGISTRATION_ID}
```
(Copy the exact value from the Single Sign-On section of your Team settings)

Logout URL:
```
https://api.loadster.com/logout/saml2/slo
```
Click Save

Configure User Attributes & Claims

Click Edit on Attributes & Claims

Ensure the following claims are configured:

Claim Name	Source Attribute
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`	user.mail
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`	user.givenname
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`	user.surname
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`	user.displayname

Click Save

Assign Users or Groups

Navigate to Users and groups in your Enterprise Application
Click Add user/group
Select the users or groups that should have access to Loadster via SSO
Click Assign

Download Federation Metadata

Go back to Single sign-on → SAML
In section 3 (SAML Certificates), find Federation Metadata XML
Click Download to save the XML file

Finish in Loadster

In the Single Sign-On section of your Loadster Team settings, paste your identity provider’s metadata URL or XML and save it. Then test signing in and turn single sign-on on, as described in Setting Up SSO in Loadster.

Okta Setup

Prerequisites

Admin access to your Okta organization
Permission to create applications in Okta

Create Application in Okta

Sign in to Okta Admin Console (https://your-domain.okta.com/admin)
Navigate to: Applications → Applications → Create App Integration
Select SAML 2.0
Click Next

General Settings

App name: Enter “Loadster” (or your preferred name)
App logo: (Optional) Upload a logo
Click Next

Configure SAML Settings

In the SAML Settings section, enter the following:

Single sign-on URL:
```
https://api.loadster.com/login/saml2/sso/{REGISTRATION_ID}
```
Copy the exact value from the Single Sign-On section of your Team settings.
- Check Use this for Recipient URL and Destination URL
Audience URI (SP Entity ID):
```
https://api.loadster.com/saml2/service-provider-metadata/{REGISTRATION_ID}
```
Copy the exact value from the Single Sign-On section of your Team settings.
Default RelayState: (leave blank)
Name ID format: EmailAddress
Application username: Email

Click Show Advanced Settings

Response: Signed
Assertion Signature: Signed
Signature Algorithm: RSA-SHA256
Digest Algorithm: SHA256
Assertion Encryption: Unencrypted

Attribute Statements

In the Attribute Statements section, add the following mappings:

Name	Name format	Value
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`	Unspecified	`user.email`
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`	Unspecified	`user.firstName`
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`	Unspecified	`user.lastName`
`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`	Unspecified	`user.displayName`

Click Next

Feedback

Select I’m an Okta customer adding an internal app
Check This is an internal app that we have created
Click Finish

Assign Users or Groups

In your new application, go to the Assignments tab
Click Assign → Assign to People or Assign to Groups
Select the users or groups that should have access to Loadster
Click Assign and Done

Download Metadata

Go to the Sign On tab
Scroll down to SAML 2.0 section
Right-click on Identity Provider metadata link
Select Save Link As… to download the XML file

Finish in Loadster

Google Workspace Setup

Prerequisites

Super Admin access to your Google Workspace account
Permission to create custom SAML applications

Access SAML Apps

Sign in to Google Admin Console (https://admin.google.com)
Navigate to: Apps → Web and mobile apps
Click Add App → Add custom SAML app

App Details

App name: Enter “Loadster” (or your preferred name)
Description: (Optional) Enter a description
App icon: (Optional) Upload an icon
Click Continue

Google Identity Provider Details

Click Download Metadata to save the XML file (you’ll need this later)
Click Continue

Service Provider Details

Enter the following information:

ACS URL:
```
https://api.loadster.com/login/saml2/sso/{REGISTRATION_ID}
```
(Copy the exact value from the Single Sign-On section of your Team settings)

Entity ID:
```
https://api.loadster.com/saml2/service-provider-metadata/{REGISTRATION_ID}
```
(Copy the exact value from the Single Sign-On section of your Team settings)

Start URL: (leave blank)

Signed response: Check this box

Name ID format: EMAIL

Name ID: Basic Information > Primary email
Click Continue

Attribute Mapping

Click Add Mapping for each of the following:

Google Directory attributes	App attributes
Primary email	`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
First name	`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`
Last name	`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`
Primary email	`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`

Click Finish

Turn On Service for Users

Click on the newly created “Loadster” app
Click User access
Select:
- ON for everyone - To enable for all users in your organization
- OFF for everyone, then create access for specific organizational units - To enable for specific departments/groups
Click Save

Finish in Loadster

Verifying Your Email Domains

Verifying the email domains your company owns keeps your identity provider from signing in anyone else. Once your team has a verified domain, your identity provider can sign in people on your verified domains, plus anyone it has already signed in. Contractors and guests on other domains sign in with their own password or Google, GitHub, or Microsoft account instead.

To verify a domain, a team admin adds it under Verified Domains on the Team page of your Loadster settings. Loadster shows a TXT record to add to your DNS:

Name: _loadster-verification.yourcompany.com
Value: a token unique to your team

After adding the record, click Verify. DNS changes can take a while to show up, so if verification doesn’t find the record right away, try again in a few minutes. You can remove the TXT record once the domain is verified. Only one Loadster team can verify a given domain.

Teams whose SSO we set up by hand keep working as before until they verify their first domain.

Requiring Single Sign-On for Your Loadster Team

Once SSO is set up for your team, a team admin can require it under Security on the Team page of your Loadster settings. The switch is available on plans that include team security requirements. If it’s unavailable for your team, contact sales@loadster.com.

With single sign-on required, the people it covers sign in through your identity provider. Logging in with a password or with a Google, GitHub, or Microsoft account is turned away for them, and they join through SSO rather than by invitation.

Who the requirement covers depends on whether your team has verified domains:

No verified domains: everyone on the team.
Verified domains: only people whose email address is on one of your verified domains. Everyone else, like contractors and guests, keeps signing in with their own password or Google, GitHub, or Microsoft account, and you can still invite them.

For example, once you verify yourcompany.com, jane@yourcompany.com has to sign in through your identity provider, while a contractor at sam@gmail.com keeps signing in the way they always have.

Turning the requirement on signs everyone else on the team out of the dashboard, so the next sign-in for anyone it covers goes through your identity provider. Personal access tokens and connected AI assistants keep working.

SCIM 2.0 User Provisioning

SCIM (System for Cross-domain Identity Management) automatically synchronizes users between your identity provider and Loadster. This eliminates the need to manually manage user access and ensures that employees who leave your organization are immediately deprovisioned.

What SCIM Provides

Automatic user creation - New users are created when assigned in your IdP
Automatic deprovisioning - Users are removed when unassigned or deleted in your IdP
Profile synchronization - User attributes (name, email) are kept in sync
Just-in-time updates - Changes propagate immediately to Loadster

How It Works

Loadster’s SCIM endpoints conform to the standard, as follows:

GET /scim/v2/ServiceProviderConfig - Configuration metadata (public)
GET /scim/v2/Schemas - Schema definitions (public)
GET /scim/v2/ResourceTypes - Resource types (public)
GET /scim/v2/Users - List users (requires auth)
GET /scim/v2/Users/{id} - Get user (requires auth)
POST /scim/v2/Users - Create user (requires auth)
PUT /scim/v2/Users/{id} - Update user (requires auth)
PATCH /scim/v2/Users/{id} - Patch user (requires auth)
DELETE /scim/v2/Users/{id} - Delete user (requires auth)

Supported Identity Providers

SCIM is an open standard (IETF RFCs 7643/7644) supported by many identity providers:

Microsoft Entra ID (Azure AD)
Okta
Google Workspace
OneLogin
JumpCloud
And many others

Setting Up SCIM

Step 1: Request SCIM Token

Contact your Loadster support representative to request a SCIM provisioning token. This is a special authentication token used by your identity provider to communicate with Loadster’s SCIM API.

Token characteristics:

Team-specific: Each token is scoped to your team
Long-lived: Does not expire or get revoked on password changes
Secure: High-entropy random token

Step 2: Configure Your Identity Provider

Microsoft Entra ID

Go to Azure Portal → Entra ID → Enterprise Applications
Select or create your application (same as used for SAML)
Navigate to Provisioning → Automatic
Configure:
- Tenant URL: https://api.loadster.com/scim/v2
- Secret Token: The SCIM token provided by Loadster
Click Test Connection to verify
Set up attribute mappings (usually defaults are fine):
- userName → userPrincipalName
- name.givenName → givenName
- name.familyName → surname
- emails[type eq "work"].value → mail
- active → (leave as default)
Click Save
Enable provisioning by setting Provisioning Status to On
Click Save and Start provisioning

Okta

Go to Okta Admin → Applications
Select your application (same as used for SAML)
Navigate to Provisioning → Configure API Integration
Check Enable API integration
Configure:
- Base URL: https://api.loadster.com/scim/v2
- API Token: The SCIM token provided by Loadster
Click Test API Credentials to verify
Click Save
Enable provisioning features:
- To App → Create Users, Update User Attributes, Deactivate Users
Map attributes in the Provisioning → To App settings
Save and assign users/groups to the application

Google Workspace

Note: at least some versions of Google Workspace only allow SCIM for apps officially vetted by Google. Please check with us on the current status of this.

Sign in to Google Admin Console (https://admin.google.com)
Navigate to: Apps → Web and mobile apps
Select your Loadster application (same as used for SAML)
Click Provisioning
Click Configure Provisioning
Configure:
- SCIM Base URL: https://api.loadster.com/scim/v2
- Authorization: Select Bearer token
- Access Token: The SCIM token provided by Loadster
Click Test Connection to verify
Click Continue
Enable provisioning features:
- Create new users - Check this box
- Update existing users - Check this box
- Delete users - Check this box
Set up attribute mappings (usually defaults are fine):
- userName → Primary Email
- name.givenName → First Name
- name.familyName → Last Name
- emails[type eq "work"].value → Primary Email
- active → (leave as default)
Click Finish
Click Turn on provisioning to enable
Users assigned to the Loadster app will now be automatically provisioned

Note: Google Workspace may take several minutes to complete the initial sync.

Troubleshooting

SAML Authentication Issues

“Invalid SAML response” - Verify that the Entity ID and ACS URL exactly match the values we provided
“User not authorized” - Ensure the user is assigned to the application in your IdP
“Missing claims” - Verify all required claims (email, givenname, surname, name) are configured
A test sign-in fails - The Single Sign-On section of your Team settings says why. Check that the Entity ID and Reply (ACS) URL in your identity provider match the ones Loadster shows, and save fresh metadata if your identity provider’s certificate changed
“Your email address isn’t on one of your team’s verified domains” - Your identity provider tried to sign in someone outside your verified domains whom it hasn’t signed in before. Verify their domain, or have them sign in with their own password or Google, GitHub, or Microsoft account

SCIM Provisioning Issues

“401 Unauthorized” - Verify the SCIM token is correct and hasn’t been revoked
“403 Forbidden” - Contact Loadster support to ensure your token is properly configured for provisioning
“Connection failed” - Verify the Tenant URL is https://api.loadster.com/scim/v2 (no trailing slash)
Users not syncing - Check provisioning logs in your IdP for detailed error messages

Support

For assistance with SSO setup or other questions, please email help@loadster.com.