LMS SSO: SAML vs OpenID Connect, provisioning and pitfalls

LMS SSO lets learners and staff sign in to your learning platform with the account they already use at work or university, such as Microsoft Entra ID, Okta or Google Workspace. The LMS trusts an identity provider (IdP) to authenticate the user and receives a signed assertion or token saying who they are. The two protocols that matter are SAML 2.0 and OpenID Connect (OIDC). Both are secure and mature; the right one is usually whichever your IdP and LMS support most completely.

Login is the easy part. The decisions that make or break an LMS SSO rollout are how accounts get created and removed, how IdP attributes map to LMS roles, cohorts and courses, what happens at logout, and where multi-factor authentication is enforced. This guide covers each, with notes for Moodle, WordPress-based LMSs, Open edX and Canvas.

What SSO does, and what it does not

SSO answers one question: is this person who they claim to be? It removes separate LMS passwords, centralises MFA and lets IT disable access in one place. It does not, on its own:

• create accounts before a user's first login (so managers cannot assign training to new hires in advance);
• remove or suspend LMS accounts when someone leaves;
• enrol users into courses, groups or cohorts unless you build that mapping;
• sign users out of the IdP when they log out of the LMS.

Plan those four items explicitly and your rollout will be uneventful.

SAML vs OIDC for an LMS: how they compare in practice

SAML 2.0 is an XML-based standard that has been the default for enterprise and higher-education federation for many years. The LMS acts as the service provider (SP), exchanges metadata with the IdP, and receives a signed XML assertion through the browser. OpenID Connect is an identity layer on top of OAuth 2.0 that returns a signed JSON Web Token (the ID token). OIDC Core 1.0 was finalised in 2014 and, together with its discovery, registration and logout specifications, was published as ISO/IEC standards in 2024.

Rules of thumb: if the organisation already federates everything through SAML (common in universities and large enterprises), use SAML. If you are greenfield on a cloud IdP, have a mobile app, or want the same identity for LMS APIs, OIDC is usually simpler to operate, mainly because key rotation is automatic.

Identity providers: Entra ID, Okta and Google Workspace

• Microsoft Entra ID supports both SAML and OIDC enterprise applications, app roles, group claims and automatic provisioning to applications that expose a SCIM endpoint.
• Okta supports SAML and OIDC applications and SCIM provisioning, including creating users, updating attributes, deactivating accounts (setting them inactive rather than deleting them) and pushing groups.
• Google Workspace lets admins create custom SAML apps with attribute mapping and group membership mapping, where the SAML response includes only the groups the user belongs to, up to a limit per app. Plan provisioning separately if you rely on Google.

Whatever the IdP, agree on one immutable identifier for the user (an object ID or employee number) rather than email address. Emails change on marriage, rebrands and domain migrations; an LMS keyed on email will create duplicate accounts and orphan completion history.

Provisioning: just-in-time vs SCIM

Just-in-time (JIT) provisioning creates the LMS account the first time a user signs in, using attributes in the assertion or token. It is quick to implement and fine for open catalogues and universities where students arrive on their own.

SCIM (System for Cross-domain Identity Management) is a REST standard where the IdP pushes create, update and deactivate operations to the LMS. It is the right choice when:

• managers must assign mandatory training before a new starter's first login;
• leavers must be deactivated promptly for compliance or licence reasons;
• department, manager or location changes must flow into reporting without waiting for the next login.

Few LMSs ship a complete SCIM server, so SCIM usually means a plugin or a small custom service. An alternative is HRIS-driven provisioning, covered in our guide to LMS integrations with HRIS, CRM and payments. Whichever route you choose, suspend accounts rather than delete them so completion records and certificates survive.

Mapping attributes to roles, cohorts and courses

Attribute mapping is where most of the real work sits. Decide which attributes arrive (given name, surname, email, immutable ID, department, country, groups) and what each drives in the LMS: profile fields, system roles, cohorts or groups, and automatic course enrolments.

A practical pitfall with Microsoft Entra ID is group overage. According to Microsoft's documentation, SAML assertions carry at most 150 groups and JWTs at most 200; beyond that the group claim is omitted and replaced with a pointer to Microsoft Graph. Users in many groups then silently lose their LMS roles. Microsoft recommends emitting only groups assigned to the application, or using app roles instead. We follow the same pattern: create a handful of LMS-specific groups or app roles (learner, instructor, manager, admin, plus cohort groups) and map only those.

Two more rules: never grant site administrator rights from an IdP attribute without a second control, and make sure the mapping removes roles as well as adding them, otherwise privileges only ever accumulate.

Logout, sessions and MFA

Users expect "log out" to end everything. In reality there are three sessions: the LMS session, the IdP session and sometimes an LTI tool's session. Decide whether LMS logout should also end the IdP session (SAML SLO or OIDC RP-initiated logout) and whether an IdP-side sign-out should end LMS sessions (OIDC back-channel logout, where supported). On shared computers in classrooms and training centres, full logout matters; for knowledge workers, a short LMS session timeout is often enough.

Enforce MFA at the IdP with conditional access policies, not inside the LMS, so there is one policy to audit. For administrators and instructors with grading rights, require phishing-resistant methods such as passkeys or security keys where the IdP supports them.

Platform notes: Moodle, WordPress LMS, Open edX and Canvas

Moodle

Core Moodle includes OAuth 2 login for common providers and custom issuers. For SAML, the widely used auth_saml2 plugin embeds SimpleSAMLphp, supports attribute mapping, optional automatic user creation, multiple IdPs and Single Logout. Microsoft's OpenID Connect plugin is a common choice for Entra ID. Cohort sync usually needs a small custom rule or plugin.

WordPress LMS plugins

LearnDash, Tutor LMS and similar plugins use WordPress user accounts, so SSO is added at the WordPress layer with a SAML or OIDC plugin. Role and group mapping into the LMS plugin's groups is typically custom work, and SSO plugins must be patched as carefully as any other authentication code.

Open edX

Open edX third-party authentication supports OAuth providers such as Google and Azure AD, SAML 2.0 identity providers including Shibboleth federations, and LTI, according to the Open edX documentation.

Canvas

Canvas authentication providers include SAML, OpenID Connect, Microsoft, Google, LDAP and CAS, with JIT provisioning and federated attributes that can set fields such as SIS user ID and admin roles at login, per the Canvas API documentation.

A rollout plan that avoids lockouts

1. Document the claim contract. One page listing every attribute, its source in the IdP, its format and what it drives in the LMS. Both the IdP team and the LMS team sign it off.
2. Build against a test tenant. Use a staging LMS and a test application in the IdP, with test users covering each role, a user in many groups and a user with no email.
3. Link existing accounts first. Before switching the login method, populate the immutable ID on existing LMS accounts so first SSO login matches instead of duplicating.
4. Pilot with one department. Keep the old login available as a fallback for a defined period, then remove it so passwords stop being a parallel attack surface.
5. Monitor after go-live. Alert on failed assertions, spikes in new account creation and certificate expiry, and log role changes made by the mapping for audit.

Common LMS SSO pitfalls

1. Matching on email. Leads to duplicates and account takeover risk if email is not verified. Match on an immutable ID.
2. Expired SAML signing certificates. Put certificate expiry dates in monitoring, or consume IdP metadata automatically.
3. No break-glass account. Keep at least one local administrator with a strong password and MFA, stored securely and tested quarterly.
4. Clock drift. Assertions and tokens have short validity windows; run NTP on LMS servers.
5. Multi-tenant confusion. Each tenant or brand may need its own IdP and mapping; see multi-tenant LMS architecture.
6. Forgetting external users. Contractors, customers and partners may not be in the corporate IdP, so keep a second, controlled login path.

How we can help

We design and implement LMS SSO end to end: SAML or OIDC configuration, SCIM or HRIS provisioning, role and cohort mapping, and hardening of the authentication layer. See our LMS integration services or get in touch to review your identity setup.