How to Set Up OAuth2 SSO for Moodle or Totara

Summary: This guide explains how to configure OAuth2 SSO in Moodle or Totara, including issuer setup, required endpoints, redirect URI handling, field mapping, and a common custom-issuer email-verification pitfall.

This is the practical admin flow for configuring an OAuth2-based login provider, especially when the provider is not one of Moodle’s preconfigured built-in services.

What you need from the identity provider

Before creating the issuer in Moodle or Totara, collect:

• client ID
• client secret
• authorization endpoint
• token endpoint
• userinfo endpoint

If you do not have all five, stop there. Generic OAuth2 login in Moodle will not become reliable by guesswork.

Register the correct redirect URI

The identity provider must allow Moodle or Totara’s callback URL. The standard Moodle redirect URI is:

https://your-moodle-site.example.com/admin/oauth2callback.php

If this URI is not registered at the provider, the login flow will fail before Moodle can even evaluate the returned user data.

Step 1: Create or select the OAuth2 issuer

Go to the OAuth2 services area in Moodle or Totara and either:

• use a preconfigured service if your provider is already supported, or
• create a custom issuer and enter the endpoints manually

Be explicit about which flow you are using, because custom issuers do not always behave exactly like the built-in Google, Microsoft, or Facebook integrations.

Step 2: Configure the endpoints and client credentials

Enter the authorization, token, and userinfo endpoints exactly as provided by the identity platform. Then add the client ID and client secret.

At this point, a copy-paste error is far more likely than a Moodle bug.

Step 3: Map the required user fields

The SOP highlights that Moodle and Totara need at least the following fields mapped correctly:

• firstname
• lastname
• email

If the provider returns those fields under different names, map them explicitly. Do not assume that the userinfo payload matches Moodle’s preferred naming.

Step 4: Test new-user and existing-user behavior

Do not stop after one successful redirect. Test:

• first login for a new user
• repeat login for the same user
• existing local account matching
• what happens when the provider returns an unverified or changed email address

Known issue: custom issuers and email verification

The SOP flags an important problem: some documentation about turning off Require email verification applies to built-in issuers such as Google, Microsoft, or Facebook, but not necessarily to custom OAuth2 services.

In that failure mode:

1. a row is created in the linked-login table
2. the user still cannot log in
3. the account remains unconfirmed because email verification never resolves the way you expect

If you are using a generic issuer and users appear to link successfully but still cannot access the site, treat this issue as a first-class suspect.

Troubleshooting priorities

• Check the redirect URI first.
• Check the three required endpoints.
• Check the userinfo payload for first name, last name, and email.
• If using a custom issuer, test the confirmation flow explicitly rather than assuming built-in service behavior applies.

Solin specializes in Moodle and Totara SSO implementations, including OAuth2 and custom identity integrations. Need help? Contact us.