When some consumers try to add the EBSCO LTI tool or launch a preconfigured tool in Moodle it results in a "whitelabel error" page. See sceenshot: https://www.screencast.com/t/DcZdKBInoQS5

The immediate cause of the issue is that the customer implementation of Moodle is not sending us with the id_token in its form post data. This is evident (https://www.screencast.com/t/oLlzp2JP) in the network section of the inspection tab, where form data shows "error : invalid_request". This is in contrast with network calls made from EBSCO's implementation (https://www.screencast.com/t/RfeqWpPcWR) of Moodle which shows long id_token value for LTI call.

To replicate:

Log in to moodle. 

Add an activity or resource > External Tool > Set preconfigure tool to EBSCO and "Select Content" for deeplinklaunch

OR

Select an EBSCO resource already added, for resourcelinklaunch.

 List of things attempted:

• There are a number of posts in moodle forum: https://moodle.org/mod/forum/discuss.php?d=419091, https://moodle.org/mod/forum/discuss.php?d=419486, https://moodle.org/mod/forum/discuss.php?d=421832 reporting similar issues. Unfortunately, none of them have solutions posted.
• Our initial thought was that the error is caused by the Moodle version the customer is using, but we tested it on both 3.9 and 3.10 and there was no difference.
• We went to site administration > Plugins > External Tool > Manage Tools to compare the tool configuration between the customer's implementation and EBSCO's implementation. The two were identical with all the fields same. Hence it doesn't seem to be the tool configuration that is causing defect.
• We went to administration > Plugins > External Tool > Manage Tools > Manage Preconfigured Tools to add another configuration of the EBSCO tool. This creates a new client id / deployment id. This new tool was not registered to EBSCO Admin. However, this unregistered EBSCO tool still results in same issue in deeplink launch, form data showing "error : invalid request" and id_token value missing, causing the same whitelabel error for the failing implementation. Hence, we think that the defect has little to do with the EBSCOAdmin registration of the deployment.
• Debugging was set at Site administration > Development > Debugging where we set the "Debug messages level" to DEVELOPER and "Display debug messages" to check. This starts to print debugging messages in console in the inspection tab, but it did not provide any useful information for the whitelabel error.
• We are not sure if it is related to the defect, but one thing we noticed in the network calls in inspection tab were the auth calls within moodle. The auth call (https://www.screencast.com/t/CX2fmXyZO2H1) has a set-cookie attribute for response headers, and a warning that the Moodle session cookie in the response header was blocked because "SameSite" attribute is not set and defaults to "SameSite=LAX". It needs SameSite="None" to use cross site usage.

Conclusion:

According to the LTI Core 1.3 https://www.imsglobal.org/spec/lti/v1p3/#messages-and-services) specification, the platform must pass the id_token to the tool for EBSCO LTI to work. As of now, we think this is a defect on Moodle, as we were able to see some similar issues posted on Moodle forum, and we do not encounter the same issue with other LMS's.