I've noticed this bug during testing using the LTI certification suite.

This is a bug surfaced by MDL-80835, which will need to be fixed on security branches (as 80835 was landed there too to fix upcoming browser changes).

Basically, this is what's happened:

1. We always used a required_param() to validate the presence of login_hint param. ONLY the presence of it. The further validation of that param was left to library code, where the real value was taken from $_REQUEST.
   • This all worked fine, despite the param type (PARAM_INT) being wrong and actually silently converting strings to the number 0. It should be PARAM_RAW, since this is a platform-controlled value and can be a GUID/whatever. We didn't see this since we weren't USING that value, only checking it's existence in the request.
2. Now, since MDL-80835, we are USING that value, as we pass it into a cookie check and redirect back, only then continuing with the OIDC login. Basically, this means $_REQUEST will now contain the bad value (0 in some cases, depending on what's being cast to int) instead of the original (likely string) value, since we've redirected to self as part of the cookie check.
3. This then results in possible launch validation failure, since the value passed to LtiOidcLogin::validateOidcLogin() can be 0, and the check used there (it's library code) is an if (empty()) , which of course fails. See the relevant code here. If something is cast to 0 and ends up here, we'll throw an exception and block an otherwise valid launch.

Basically, the crux of the issue is that a login_hint like "93F589A7-C501-41BA-A471-C3AE8C804CE5" will be cleaned, through PARAM_INT, to the integer 93, which isn't right. Sometimes, depending on the string, this can end up converting to the integer 0, which causes launch failures.