Moodle Single Sign-On: A Practical Guide to SAML, OpenID Connect and Entra ID

Moodle single sign-on should give people one governed route into learning without creating duplicate accounts, hidden access or an administrator lockout. The protocol is only one part of that outcome.

The short answer is: use OpenID Connect when a well-supported identity provider and Moodle plugin make it the natural fit, retain SAML where it is the organisation's established federation standard, and design account matching, provisioning, enrolment, recovery and offboarding before enabling either. For Microsoft Entra ID, a tenant-specific OpenID Connect configuration is usually the cleanest starting point. Keep a tested local administrator route and roll out to a pilot group before forcing federated login.

Define What SSO Will and Will Not Do

Single sign-on answers an authentication question: who is this person, and has the identity provider authenticated them? It does not automatically answer whether they should have a Moodle account, which courses they may enter, which role they receive, or when their access should end.

Treat these as separate controls:

• Authentication: the identity provider verifies the person and Moodle accepts the resulting assertion or token.
• Account lifecycle: a process creates, updates, suspends and removes the Moodle account.
• Enrolment: cohort, group, manual, database or other rules grant course access.
• Authorisation: Moodle roles and capabilities determine what an authenticated user can do.
• Recovery: an approved route handles identity-provider failure, configuration errors and exceptional accounts.

Swift Learn's judgement is that most risky SSO projects begin with the login button and discover these boundaries later. Start with the lifecycle. Name the source of truth for staff, learners, contractors and guests; define what happens when each person joins, changes status and leaves; then choose the protocol and plugin.

Do not translate an identity-provider group directly into a powerful Moodle system role without a separate approval and review. Use the same least-privilege discipline as a Moodle roles and permissions audit.

Choose Between OpenID Connect and SAML

OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. A Moodle authentication plugin uses an ID token and the provider's published metadata and signing keys to verify the login. SAML 2.0 exchanges signed XML assertions between an identity provider and Moodle acting as a service provider.

Both can provide secure federation when they are correctly implemented and operated. The decision should follow the environment rather than a claim that one acronym is universally safer.

The Moodle Marketplace OpenID Connect authentication listing, reviewed on 4 November 2026, describes configurable OIDC identity providers and Microsoft Entra ID integration. On the same date it listed support for Moodle 4.5 to 5.2. The Marketplace SAML2 listing described user auto-creation, field mapping and identity-provider metadata configuration, with listed support through Moodle 5.1. These are dated compatibility observations, not a promise about a future upgrade: verify the exact plugin release against your supported Moodle branch and test it before every platform upgrade.

Choose the implementation your team can patch, monitor and recover. Protocol familiarity is useful, but maintained compatibility, lifecycle fit and an accountable operational owner matter more.

Design the Identity Mapping Before Configuration

The most consequential setting is often the value used to recognise an existing person. Email addresses look convenient but may change after a rename, merger or domain migration. They may also be recycled. Display names are not unique. Moodle usernames may follow historic rules that do not match the identity provider.

Prefer a stable, unique identifier issued by the identity system, then document how it maps to the Moodle record. Before first login:

1. export and analyse current authentication methods, usernames and duplicate email addresses;
2. identify accounts that already belong to the pilot population;
3. define whether matching links an existing account or creates a new one;
4. test name changes, changed email addresses, guests and returning users; and
5. decide how an incorrect match is detected and reversed without losing learning records.

Never test automatic matching for the first time against the full production population. A duplicate account can divide grades, completion history and certificates between two records. An incorrect link can expose another person's data.

Keep profile mapping minimal. Decide which system owns given name, family name, email and organisational fields, and whether Moodle may overwrite a local change at every login. Record the rule for empty or withdrawn attributes. If a field drives cohorts, reports or integrations, treat a mapping change as a data migration and include it in the controls used for a Moodle migration.

Configure Microsoft Entra ID Deliberately

For an Entra-backed OIDC design, register Moodle as a web application and use the callback or redirect URI supplied by the selected Moodle plugin. The URI in Entra must match the application's value exactly, including scheme, host, path and, where relevant, trailing slash.

Microsoft's OpenID Connect documentation, updated 6 October 2026 and reviewed here on 4 November 2026, explains that OIDC uses ID tokens and publishes discovery metadata under the tenant authority. It distinguishes tenant-specific identifiers from common, organizations and consumers authorities. For a Moodle site intended for one organisation, Swift Learn normally starts with the specific Entra tenant rather than accepting a broader audience unintentionally.

During design and configuration:

• copy the plugin's exact redirect URI into the app registration;
• restrict the sign-in audience to the approved tenant or tenants;
• request only the identity claims and permissions the integration needs;
• agree which stable claim identifies the Moodle account;
• store client credentials outside documentation and source control;
• assign an owner and alert date for secret or certificate rotation;
• apply conditional access and multifactor authentication at the identity layer according to organisational policy; and
• document the Moodle and Entra administrators who can approve a change.

OIDC discovery reduces hand-entered endpoints, but it does not remove governance. Validate the configured issuer and tenant, protect the client credential, and test rotation before the current credential expires. A calendar reminder owned by someone who has left is not a rotation process.

Configure SAML With the Same Lifecycle Discipline

For SAML, exchange metadata between Moodle and the identity provider through an approved channel. Confirm the Moodle service-provider entity ID and assertion consumer service URL, the identity-provider entity ID and sign-in URL, the signing requirements, and the attributes used for account mapping.

Agree how certificate rollover is communicated and tested. Monitor the expiry date, but also account for a provider publishing old and new certificates during a transition. Check time synchronisation on Moodle infrastructure because assertions have validity windows. Decide whether single logout is required and verify its actual behaviour across the identity provider, Moodle, browser and other applications; a Moodle logout link does not necessarily end every upstream session.

SAML attribute names and NameID formats vary between federations. Capture a redacted assertion in a controlled test environment and compare the received values with the mapping design. Do not weaken signature validation or extend validity windows merely to make an unexplained test failure disappear.

Preserve Administrative Recovery

Never make the only site administrator dependent on the new SSO path. Maintain at least one named, tightly controlled local break-glass account with a strong unique credential, restricted use and monitored access. Store its recovery material under the organisation's emergency-access process and test it on a schedule.

During rollout, leave the existing login method available while the pilot proves successful. Record how an administrator can reach the local login route if the federated button becomes automatic. A recovery route that nobody can find during an identity-provider incident is not a control.

Service accounts and integration users need an explicit decision. Interactive SSO is usually the wrong mechanism for scheduled imports, web services or monitoring. Use a supported non-interactive authentication design, minimal permissions, credential rotation and a documented owner rather than allowing a shared human account to bypass policy.

Test the Whole Login and Learning Journey

Use a staging environment with the same hostname pattern, HTTPS behaviour, Moodle release and plugin versions as production. Register its callback separately; do not keep changing the production redirect URI for tests.

Test mobile browsers, the Moodle app if it is supported, deep links, password-reset messaging, accessibility and the return destination after login. Confirm course enrolment, gradebook visibility, completion and downstream reporting for the same account. Authentication success alone is not acceptance.

Review logs on both sides. Record a correlation identifier and timestamp for failed tests without copying tokens or personal claims into tickets. Define who investigates issuer, redirect, signature, claim and clock errors, and how the identity and Moodle teams hand an incident between them. Those responsibilities belong in a practical Moodle support contract, not only in an implementation note.

Roll Out in Controlled Stages

Start with administrators who are not the sole recovery owners, then a small staff and learner cohort, then expand by an observable rule. Publish a plain-language notice explaining the new sign-in route, which organisational account to use, where to obtain help and what happens to existing Moodle credentials.

For each phase, monitor successful and failed logins, account creation, duplicate reports, support contacts and unexpected profile changes. Set a rollback threshold before launch. Rollback may mean disabling the new method, restoring the previous login choice or pausing automatic account creation; rehearse it without deleting accounts or learning data.

Include SSO requirements in hosting and procurement decisions. Callback URLs, reverse proxies, HTTPS termination, plugin deployment, outbound connectivity, log access and emergency change support all affect the integration. The Moodle hosting RFP checklist provides a wider framework for making those responsibilities explicit.

The Swift Learn Verdict

A good Moodle SSO implementation is an identity-lifecycle project with a login protocol inside it. OIDC is often the practical choice for Microsoft Entra ID and other modern providers; SAML remains appropriate where federation standards, partner requirements or existing operations support it better.

The decisive trade-off is convenience versus controlled dependency. Central identity can strengthen multifactor authentication, access policy and offboarding while reducing password friction. It also makes Moodle dependent on correct claims, maintained plugins, valid credentials and a reachable identity provider. Design the account match, lifecycle, recovery and monitoring with the same care as the protocol, and the convenience becomes governable rather than fragile.

Need a Moodle SSO Design Review?

Bring us your Moodle version, current authentication methods, identity-provider requirements and a sample user lifecycle. Swift Learn will map the protocol choice, account matching, Entra or SAML configuration, recovery controls, test plan and rollout risks into an implementation-ready design.