Email:info@softosmith.com
Working Hours:Mon - Fri: 9 AM - 5 PM (PKT)
A technical look at how single sign-on actually works with Moodle — the protocols it supports, how the SAML2 flow behaves with real identity providers, and the attribute-mapping and certificate details that most SSO rollouts get wrong the first time.
Once Moodle sits alongside HR systems, email, and a dozen other SaaS tools, a separate Moodle password becomes a support burden and a security gap — password reset tickets pile up, offboarded employees keep access longer than they should, and IT has no single place to enforce MFA.
A separate Moodle credential is one more password to forget, reset, and eventually reuse unsafely elsewhere.
Disabling a user in your identity provider doesn't touch their Moodle account unless SSO is actually wired up.
Multi-factor policies enforced at the IdP don't protect Moodle at all if Moodle authenticates independently.
Moodle ships several authentication plugins capable of single sign-on, each suited to a different identity setup.
Moodle's SAML2 authentication plugin (auth_saml2, bundled with core since Moodle 3.3+) handles the SP side of the SAML exchange, redirecting users to your identity provider and consuming the signed assertion it returns.
Moodle's OAuth2 authentication plugin ships preset configurations for Google and Microsoft, plus a generic issuer type for any OAuth2/OpenID Connect provider that exposes the right endpoints.
Still common in universities running older campus identity infrastructure. Moodle's CAS plugin authenticates against a Central Authentication Service server, typically alongside LDAP for attribute lookup.
LDAP authenticates Moodle logins directly against a directory but doesn't provide true single sign-on across other apps. Many organizations pair it with SAML2 or OAuth2 rather than using it alone.
This is the standard service-provider-initiated flow that runs every time a user logs into Moodle through SAML2.
The user navigates to your Moodle site (or an activity link shared from your LMS) without an active session.
auth_saml2 builds an AuthnRequest and redirects the browser to your identity provider's SSO endpoint — Azure AD, Okta, or whichever IdP is configured.
The user logs in (and satisfies MFA, conditional access, or other IdP-side policy) entirely on the identity provider's domain — Moodle never sees the password.
The IdP returns a signed SAML response to Moodle's Assertion Consumer Service (ACS) URL, containing the user's attributes and authentication statement.
auth_saml2 verifies the signature against the IdP's certificate, then maps SAML attributes to Moodle profile fields per your configured attribute mapping.
If the user already exists (matched on idnumber, username, or email per your configuration), Moodle logs them in. If not, and JIT provisioning is enabled, a new account is created on the fly.
The protocol is the same across identity providers, but the setup details — and where things go wrong — differ enough to be worth calling out individually.
Configured as a SAML2 enterprise application or via auth_oauth2's Microsoft preset. Entra ID's SAML metadata URL feeds auth_saml2's IdP metadata field directly — avoid hand-typing certificate fingerprints.
Set up as a SAML2 app integration in Okta with the ACS URL and Entity ID from Moodle's auth_saml2 settings page. Okta's attribute statements need explicit mapping to match what Moodle expects.
Either a custom SAML app in the Google Admin console, or Moodle's built-in Google preset under auth_oauth2 for organizations that just need Workspace-account login without full SAML complexity.
A common on-premises IdP for organizations not yet on Entra ID. Requires a relying party trust configured with Moodle's exact Entity ID and ACS URL, and claim rules mapping AD attributes to SAML claims.
Frequent in higher education federations (InCommon, eduGAIN). auth_saml2 interoperates with Shibboleth IdPs the same way as any SAML2 IdP, provided metadata exchange is done correctly.
Getting SSO to authenticate a user is the easy part. Mapping who they are inside Moodle — correctly, and consistently across logins — is where most implementation time actually goes.
Mapping a stable, unique IdP attribute (an employee or student ID, not email) to Moodle's idnumber field is the most reliable way to match returning users across logins.
Email works for matching but breaks when organizations change email domains or when users have multiple email aliases at the IdP — a poor sole source of truth for identity matching.
IdP group or department attributes can drive cohort sync or role assignment through Moodle's cohort sync enrolment method, rather than manually assigning roles after every SSO login.
auth_saml2 can create a Moodle account automatically on first successful login when no matching user exists, using mapped attributes to populate the new profile — useful for large populations you don't want to pre-provision.
Almost every SSO issue we've been called in to fix falls into one of these categories.
SAML assertions carry tight validity windows (NotBefore/NotOnOrAfter). If your Moodle server's clock drifts from the IdP's, valid assertions get rejected as expired. NTP sync on the Moodle server is non-negotiable.
IdPs rotate signing certificates on a schedule. If auth_saml2 is configured with a static certificate instead of a live metadata URL, rotation silently breaks every login until someone updates it.
The exact attribute name the IdP sends (e.g. http://schemas.xmlsoap.org/claims/EmailAddress vs a bare 'email') has to match what's configured in auth_saml2's attribute mapping, or fields come through empty.
Supporting more than one identity provider (say, a university federation plus a partner organization) means configuring multiple IdP entries in auth_saml2 and giving users a way to pick the right one, since Moodle doesn't auto-detect which IdP a user belongs to.
The Moodle Mobile app opens SSO flows in an in-app browser and expects a specific redirect back into the app (moodlemobile:// custom URL scheme). IdPs or proxies that block redirects to custom schemes will strand mobile users mid-login.
Migrating from manual accounts to SSO usually means a transition period where both auth_manual and auth_saml2 are active — existing accounts need their auth method and idnumber reconciled, or SSO logins create duplicate accounts instead of matching existing ones.
SSO configuration built on real experience with Moodle's authentication plugin architecture, not a generic identity-management playbook.
Configuration verified in staging against your real identity provider before it ever touches production logins.
Attribute mapping built around your real idnumber, role, and cohort structure, not a generic default that half-matches your data.
SSO tested in the Moodle Mobile app as well as the browser, so learners on iOS and Android aren't the ones who discover it's broken.
Straight answers to what comes up most before an SSO rollout.
Natively. auth_saml2 has shipped as a core-bundled authentication plugin since Moodle 3.3, and auth_oauth2 and auth_cas are also core plugins. No paid add-on is required for standard SAML2, OAuth2, or CAS single sign-on.
Yes. Moodle supports multiple enabled authentication methods simultaneously. The common pattern during migration is running auth_saml2 alongside auth_manual, then progressively restricting manual login as accounts move over to SSO.
SAML2 is the standard for enterprise identity federation (Azure AD, Okta, ADFS, Shibboleth) and is what most institutional IdPs expect. OAuth2/OpenID Connect is lighter weight and is what auth_oauth2's built-in Google and Microsoft presets use — often simpler to set up when you just need 'login with your Google Workspace account' rather than full claims-based federation.
By whichever field you configure as the matching key in auth_saml2 or auth_oauth2 — typically idnumber, username, or email. Getting this mapping right before go-live matters, because a mismatch either fails logins for existing users or creates duplicate accounts.
Yes, this is just-in-time (JIT) provisioning. auth_saml2 can create a new Moodle account on first successful SSO login using attributes from the assertion, without an administrator pre-creating accounts.
Yes, but it requires the 'Web services' and mobile-specific SSO handling to be configured correctly — the mobile app opens the IdP login in an embedded browser and needs to redirect back into the app via a custom URL scheme. This is one of the most common things that gets missed in a first SSO rollout.
If auth_saml2 is pointed at a live IdP metadata URL rather than a manually pasted certificate, Moodle picks up the new certificate automatically. If the certificate was hardcoded, every login breaks the moment the old certificate expires — this is the single most common cause of SSO outages we see.
The full overview of our Moodle development services, pricing, and process.
Caching, database, and server configuration for Moodle sites under real load.
Custom plugins and full theme builds, upgrade-safe from the ground up.
SCORM, xAPI, cmi5, and LTI connections into Moodle.
Tell us which identity provider you're on and we'll scope the integration.
Talk to a Moodle SSO Developer
