| Single sign-on lets people log into your LMS with their existing company credentials, so there is no separate password. User provisioning creates, updates and removes their accounts automatically as staff join, change roles or leave. SSO handles who can log in; provisioning handles which accounts exist. Together they make LMS access secure and hands-off. |
Two Different Jobs: Login and Accounts
SSO and provisioning are often lumped together, but they solve two distinct problems, and understanding the difference is the key to the whole topic.
Single sign-on, or SSO, is about authentication: it lets an employee log into your LMS using the same credentials they already use for everything else, through an identity provider such as Okta or Microsoft Entra ID. No separate LMS password to create, forget or reset. Provisioning is about account lifecycle: automatically creating an account when someone joins, updating it when they change roles, and removing access when they leave.
| The one-line distinction: SSO controls who can log in. Provisioning controls which accounts exist in the first place, and when they are switched off. You usually want both. |
How SSO Works (SAML in Plain Terms)
Most LMS single sign-on runs on a standard called SAML, with newer systems also supporting OIDC. The mechanics are simpler than the acronyms suggest.
When a user tries to reach the LMS, the LMS asks the company's identity provider to confirm who they are. The identity provider checks the user is validly logged in and sends back a secure, signed assertion vouching for them. The LMS trusts that assertion and lets them in. The user never types an LMS-specific password, and the company keeps a single, central place to control access.
- One set of credentials: users log in with their existing company identity.
- Central control: disable someone in the identity provider and their LMS login stops working.
- Fewer passwords: nothing LMS-specific to forget, reset or leak.
- Stronger security: authentication policies such as MFA are enforced centrally.
Why SSO Alone Is Not Enough
A lot of buyers assume SSO covers everything. It does not, and the gap matters most at the worst possible moment: when someone leaves.
Many platforms create accounts through just-in-time provisioning, meaning the account is made the first time a user logs in via SSO. That works fine for onboarding. But it does nothing for offboarding: when an employee is disabled in the identity provider, no login happens, so the LMS never receives an update. The account, its data and any access can linger. For that, you need real provisioning.
| Just-in-time provisioning handles the first login well and offboarding not at all. If the only mechanism is JIT, terminated users can keep lingering LMS accounts. That is a security and compliance gap. |
How Provisioning Works (SCIM in Plain Terms)
Automated provisioning usually runs on a standard called SCIM. Where SAML handles login, SCIM keeps the actual accounts in sync between your identity provider and the LMS, in both directions of the lifecycle.
- Create: when HR adds someone to the directory, SCIM creates their LMS account automatically, before they ever log in.
- Update: when someone changes role, department or name, those attributes update in the LMS without a manual edit.
- Deactivate: when someone is removed in the identity provider, SCIM deactivates their LMS account promptly, closing the offboarding gap.
- Groups: team or department membership can sync, which is powerful when training is assigned by group.
| SSO (SAML) | Provisioning (SCIM) | |
| Job | Authenticates login | Manages account lifecycle |
| Handles onboarding | At first login (JIT) | Before first login, automatically |
| Handles offboarding | No | Yes, deactivates on removal |
| Keeps roles in sync | No | Yes |
What to Ask an LMS Vendor
Because these two capabilities are easy to conflate, it is worth asking specific questions before you buy, especially if you have more than a few hundred users.
- Do you support SAML SSO, and with which identity providers (Okta, Microsoft Entra ID, others)?
- Do you support SCIM provisioning, or only just-in-time account creation at login?
- When someone is disabled in our identity provider, does their LMS account deactivate automatically?
- Can group or department membership sync, so training assignment by group stays current?
- How are role changes reflected, and how quickly?
| The single most revealing question: 'when we offboard someone, what happens to their LMS account, and how?' If the answer relies on a manual step, that is a gap you will eventually pay for. |
SSO and Provisioning in MyPass LMS
MyPass LMS supports single sign-on so learners access training with their existing company credentials, and it handles user provisioning so accounts are created, updated and deactivated in step with your systems rather than by hand. Combined with bulk onboarding and its AMS integrations, that keeps the right people in the platform with the right access, automatically.
The practical payoff is less admin and fewer security gaps: new joiners get access without manual account creation, role changes flow through, and leavers lose access promptly. For associations, the same principle extends to member records syncing bidirectionally with the AMS.
The bottom line
SSO and provisioning solve two different problems, and secure, low-admin LMS access needs both. SSO, usually via SAML, controls who can log in with existing credentials. Provisioning, usually via SCIM, controls which accounts exist and, crucially, deactivates them when people leave. Relying on SSO with just-in-time creation alone leaves an offboarding gap.
When you evaluate platforms, ask specifically about both. See how access, bulk onboarding and integrations work in MyPass LMS features, or start a free trial to test them with your identity provider.
Frequently asked questions
What is the difference between SSO and user provisioning?
SSO, single sign-on, controls authentication: it lets users log into the LMS with their existing company credentials. User provisioning controls account lifecycle: creating, updating and deactivating accounts as people join, change roles or leave. SSO decides who can log in; provisioning decides which accounts exist. Secure, low-admin access needs both.
What is the difference between SAML and SCIM?
SAML is the standard behind single sign-on; it authenticates a user's login by exchanging a signed assertion between your identity provider and the LMS. SCIM is the standard behind provisioning; it automatically creates, updates and deactivates accounts to keep the LMS in sync with your directory. SAML handles login, SCIM handles account lifecycle.
Why is SSO alone not enough for an LMS?
Many platforms create accounts through just-in-time provisioning at first login via SSO, which handles onboarding but not offboarding. When an employee is disabled in the identity provider, no login occurs, so the LMS is never told to remove them and the account can linger. SCIM provisioning closes that gap by deactivating accounts automatically.
What should I ask an LMS vendor about identity and access?
Ask whether they support SAML SSO and with which identity providers, whether they support SCIM provisioning or only just-in-time creation, what happens to an LMS account when someone is offboarded, whether group membership syncs, and how quickly role changes are reflected. The offboarding question is the most revealing.