MDL-71887 resolved a critical issue impacting LTI launches in some browsers. Specifically, those which block third party cookies. You can read there for more information about the specifics of that problem.

Part of the solution to that was to make a self-post in auth.php, so that we force the browser to send the Moodle cookie header, allowing the Moodle session to continue. This approach is fine, however, the patch there only posted the data received in $_POST to itself.

Per Section 5.1.1.2 of the IMS Security Framework 1.1 spec the behaviour of this endpoint is dictated by Section 3.1.2.1 of the OpenId core specification:
"Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 2616 [RFC2616] at the Authorization Endpoint."

Prior to 71887, since we were using optional_param() calls (which support fetching the vars from either POST or GET requests), we were fine. Auth.php would work using either GET or POST. Now (and only under situations where we are performing a self post  - which is browser +  browser config dependent), we'll be unable to self post if the original params are sent via a GET. We'll try to use $_POST directly and the auth will fail.

What we should be doing is reposting those params which are required by auth.php, after we've fetched them using the optional_param() calls. This way, it won't matter whether they came from a POST or a GET - we'll be able to repost and continue to auth just fine.