Handle 3rd party initiated login in OIDC in a different endpoint

[jkakavas]

So far we use the rp.redirect_uri both for RP initiated and 3rd party initiated logins. This should work in most cases but breaks when an OpenID Provider responds to an rp initiated Authentication Request with a redirect to the redirect_uri that contains an iss parameter.

In this case, since we check for iss first, we assume this is a new request for a Third party initiated login and we send a new Authentication Request to the OP, which ends up in an infinite loop and probably an ERR_TOO_MANY_REDIRECTS in the browser.

There is no reason for an OP to send the iss parameter in an authentication response, but at the same time the Spec dictates that an RP MUST ignore any unknown parameters when validating an authentication response.

We could try changing our logic to check for the existence of a code parameter first (or an id_token in the case of an implicit flow ) but I'd suggest we simply support and additional endpoint as the login initiation endpoint for supporting Third party initiated login.

[elasticmachine]

Pinging @elastic/kibana-security

[jkakavas]

As discussed with @azasypkin, the slightly-relevant changes in #42069 makes this a non-issue for >7.4.
I suggest we keep this open as an ER, as I believe that having a separate login initiation endpoint is probably better from a user perspective and might also allow us to simplify the OIDC auth provider code further.