You are correct: the redirect_uri parameter should be
pointing back to
Special:PluggableAuthLogin. From your example below, it should look
The redirect_url is computed by the code at , which discards all query
parameters. As long as you are being redirected to OIDC from
, you should be
fine. If you are being redirected from
the title would be stripped off.
PluggableAuth is redirected from Special:UserLogin to
Special:PluggableAuthLogin by creating the URL at  using
Title::newFromText( 'Special:PluggableAuthLogin' )->getFullURL()
and then being redirected to it. Could getFullURL() be generating the URL
in "?title=..." form on your server? Perhaps because of ? If so, please
let me know. There would have to be a fix to prevent the title query
parameter from being stripped.
Thank you Cindy. That was the hint I needed.
Although I have experience with OIDC I am new to MediaWiki and
I had not yet configured "short URLs". After making the
necessary changes in my Apache HTTP Server and MediaWiki
configurations to support short URLs the extension then began
to generate a correct redirect_uri value.
Should the use of short URLs be mentioned as a requirement for
the OpenID Connect extension, or is it the case that not using
short URLs is so rare as to not warrant mentioning it
I now have the extension interoperating with my desired OP
(not Google FWIW). I did, however, find a small bug.
The OP returns an authorization code value that is a URI. As
such it is URL-encoded in the POST body being sent back to the
extension. The extension, however, does not URL-decode the
value so when it later attempts to exchange the code for the
ID token it correctly URL-encodes the code but now it is
"double encoded" and rejected by the OP.
It appears that this is really an issue in the OpenID Connect
PHP library that the OpenID Connect extension includes. Should
I open an issue directly with that project or as the extension
author would you prefer to do that? Or should I just open an
issue for the OpenID Connect extension?