LMS SSO: SAML, OAuth, and What Enterprise Buyers Should Require

Cubite sells Cubite LMS, managed Open edX and managed Moodle, and publishes this guide.

Short answer (updated October 1, 2026): Cubite LMS costs $290 a month or $2,900 a year per site, with unlimited learners and courses.
SSO with Google, GitHub or Facebook sign-in is included at $290; SAML SSO and SCIM are Enterprise.

Ask an LMS vendor whether they support single sign-on and almost every one says yes. Ask what happens after the login button and the answers diverge fast. For an enterprise or a university, LMS SSO is not one feature, it is a stack of them, and the distance between a real implementation and a checkbox is where roll-outs stall and audits fail. This guide explains how LMS single sign-on actually works, what to require beyond the words "we support SAML", and how to evaluate it before you sign.

What single sign-on actually means for an LMS

Single sign-on lets a person reach your LMS with the same account they already use for email and every other work app, instead of a separate LMS username and password. Two parties do the work. Your identity provider, or IdP (think Okta, Microsoft Entra ID, or Google Workspace), verifies who the user is. The LMS, acting as the service provider, trusts that verification and starts a session.

The flow is deliberately hands-off for the learner. When someone opens the LMS, it sees no active session and redirects them to your IdP. The IdP checks their credentials, including any multi-factor step you enforce, and sends back a signed token. The LMS validates that token and grants access, and the user never types an LMS-specific password. OneLogin sums up the division of labor cleanly: you use SAML for authentication and OAuth for authorization.

SAML, OAuth, OIDC, LDAP and LTI, without the jargon

SAML, the Security Assertion Markup Language, is the workhorse of enterprise SSO. As OneLogin describes it, web applications use SAML to transfer authentication data between two parties, the identity provider and the service provider, in XML. The verified credential the IdP hands over is called a SAML assertion, and it is what tells the LMS this person is who they claim to be.

OAuth 2.0 and OpenID Connect are the modern pair. Okta puts the split plainly: OAuth 2.0 provides authorization via an access token containing scopes, while OpenID Connect adds authentication by introducing an ID token that carries identity. In practice, SAML still dominates corporate and campus environments, and OIDC shows up in newer web and mobile sign-in flows.

Two more standards round out an enterprise setup. LDAP and Active Directory connect the LMS to your existing user directory for provisioning and group sync. LTI, the Learning Tools Interoperability standard maintained by 1EdTech, handles single sign-on into external tools: LTI 1.3 adds deep linking, grade passback, and names-and-roles roster sync, so a proctoring tool or a publisher's content can launch inside a course without a second login.

The login button is easy. Provisioning is the hard part.

Most SSO disappointments are not about the login screen. They are about what does not happen after it. If your LMS authenticates a user through SSO but has no record of them, someone still has to create that account, assign a role, and enroll them in the right courses by hand. At a few hundred learners that is annoying. At tens of thousands, with staff joining and leaving every week, it is unworkable.

The fix is automatic provisioning. With just-in-time provisioning, the account is created on the user's first SSO login, with their name, email, role, and department mapped straight from your IdP. Group membership in the IdP can then drive enrollment, so adding someone to the "Nursing 2026" group in your directory puts them in the right courses without an administrator touching the LMS.

• Create the account on first sign-in, so there is no pre-loading of users.
• Map attributes like name, email, role, and department from the identity provider.
• Drive course and group enrollment from IdP groups, not a manual spreadsheet.
• Remove access the moment someone is deprovisioned in the directory.

The 2026 reason SSO moved up every checklist

Single sign-on used to be a convenience line item. After the 2026 Canvas data breach put learner data on the front page, it became a security control that boards ask about by name. Routing every login through one identity provider means you enforce multi-factor authentication in one place, apply your password policy everywhere, and cut off a departing employee's access to the LMS the instant you disable their directory account.

Higher education has lived this for years. Campuses federate identity through Shibboleth, the SAML-based system behind the InCommon Federation, which by its own account connects more than 1,000 research, education, and industry partners to over 6,000 services. If you serve universities, supporting that federation is not optional, and it is a fair question to put to any LMS you evaluate.

What to require before you sign

Turn the ideas above into a purchasing checklist. A vendor that answers yes to all of these has real enterprise SSO. A vendor that hedges on provisioning, MFA, or fallback is selling you a login button and calling it a platform. Work through it in your next demo and make them show, not tell.

SSO on Cubite LMS, plan by plan

Measured against the checklist above, the Growth plan covers the sign-in itself and the learner account on first sign-in. It does not connect to a corporate directory, so roles, groups and enrollments do not flow in from your identity provider: your admins set them, or another system does through the API. SAML SSO and SCIM are on the Enterprise plan.

SSO also sits on the part of Cubite that makes it enterprise-grade in the first place: every customer runs on a white-label site on its own domain, and Cubite is SOC 2, GDPR, and FERPA aligned. That isolation is why real multi-tenancy beats a logo swap, and it is the difference between SSO as a genuine security control and SSO as a convenience feature bolted onto shared infrastructure.

When you might not need enterprise SSO

Be honest about your own situation before you make SSO a dealbreaker. If you are a small team without a corporate identity provider, if your learners are the general public rather than employees, or if you run a few dozen accounts that rarely change, local logins with strong passwords and MFA are perfectly reasonable. Adding SAML there buys you complexity, not safety.

The calculus flips the moment you have an IdP, a compliance obligation, or regular onboarding and offboarding at scale. At that point manual account management is the risk, and SSO with automatic provisioning is what keeps access accurate. If the quiz above put you in the enterprise-ready band, you may already have what you need. If it did not, the checklist is your shortlist of questions.

Where Cubite fits

Cubite LMS is built for the organizations that feel this most: universities, enterprises, and training providers that run courses for people who already sign in somewhere else. Its Growth plan, $290 a month or $2,900 a year per site, gives each academy its own white-label site and signs learners in with Google, GitHub or Facebook. Signing in through Microsoft Entra ID, Okta or a campus identity provider is not part of Growth: SAML SSO and SCIM are on its Enterprise plan, and our guide to choosing a LearnDash alternative for universities and enterprise covers the rest of the institutional checklist. If you run Open edX or Moodle instead, SSO (SAML / OIDC) implementation is included in every Cubite managed Open edX tier, from $1,260 a month, and in every managed Moodle tier, from $690 a month. Our SSO integration service connects an existing Open edX site to your identity provider.