How to Set Up OAuth2 SSO for Moodle or Totara

Issues

OAuth2 is very hard to troubleshoot, but basically you should only need the 3 end points mentioned above. If the customer delivers you a couple of urls which do not work, see if they point to pages which themselves contain urls. Try these urls instead. We’ve had an example of a customer who sent us a kind of metadata url which contained the actual urls to use.

Here’s an example of such a url:

https://account.[customername].com/auth/realms/business/.well-known/openid-configuration

This url turned out to contain everything we needed (except for the proper scopes):

{

“issuer”:”lms.example.com/auth/realms/business”,

“authorization_endpoint”:”lms.example.com/auth/realms/business/protocol/openid-connect/auth”,

“token_endpoint”:”lms.example.com/auth/realms/business/protocol/openid-connect/token”,

“introspection_endpoint”:”lms.example.com/auth/realms/business/protocol/openid-connect/token/introspect”,

“userinfo_endpoint”:”lms.example.com/auth/realms/business/protocol/openid-connect/userinfo”,

“end_session_endpoint”:”lms.example.com/auth/realms/business/protocol/openid-connect/logout”,

“jwks_uri”:”lms.example.com/auth/realms/business/protocol/openid-connect/certs”,

“check_session_iframe”:”lms.example.com/auth/realms/business/protocol/openid-connect/login-status-iframe.html”,

“grant_types_supported”:[

“authorization_code”,

“implicit”,

“refresh_token”,

“password”,

“client_credentials”

],

“response_types_supported”:[

“code”,

“none”,

“id_token”,

“token”,

“id_token token”,

“code id_token”,

“code token”,

“code id_token token”

],

Issue with Email Verification in OAuth2 for Custom Services in Totara

Description of the Issue

When configuring OAuth2-based SSO in Totara, administrators may encounter an issue where the system enforces email verification for custom OAuth2 providers. Unlike predefined providers such as Google, Microsoft, and Facebook, custom services do not offer the option to disable the “Require email verification” setting in the user interface. This behavior results in user accounts being marked as “pending email confirmation,” preventing successful logins.

Observations

• This restriction does not apply to predefined OAuth2 services, where the “Require email verification” setting can be toggled.

• In Moodle 4.5, this limitation has been addressed, allowing custom OAuth2 providers to disable email verification.

• The issue stems from a default database configuration that requires email verification for custom services.

Example Scenario

Upon authentication via a custom OAuth2 provider:

1. A record is created in the oauth2_linked_login table with confirmed set to 0.

2. Users remain unable to log in until email verification is completed.

Suggested Remedy by Totara

Totara HQ has provided an unsupported workaround involving a direct database query. The query modifies the oauth2_issuer table to disable the email verification requirement for a specific OAuth2 service:

UPDATE [prefix]_oauth2_issuer

SET requireconfirmation = 0

WHERE name = “name_of_issuer_here”;

Important Notes:

• Replace [prefix] with the database prefix used in the Totara installation (e.g., ttr or mdl).

• Ensure that the name_of_issuer_here matches the exact name of the custom OAuth2 service.

Risks and Limitations

• Totara does not support this approach as it bypasses a core security measure.

• Directly modifying the database introduces a risk of unintended consequences and may compromise system security.

• Any issues arising from this change will not be supported by Totara HQ.

Recommendations

• Evaluate whether disabling email verification is essential for the specific use case.

• If email verification must be disabled, proceed with the query cautiously, ensuring a backup of the database before execution.

• Report the requirement to Totara HQ to encourage future support for this feature in the user interface.

By documenting this issue and its resolution, administrators can better understand the limitations of OAuth2 custom services in Totara and make informed decisions about implementing workarounds.