Re: PluggableAuth and OAuth and login user experience

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: PluggableAuth and OAuth and login user experience

Hi, Scott.

Some background: by default, MediaWiki core enables two authentication
providers, LocalPasswordPrimaryAuthenticationProvider and
TemporaryPasswordPrimaryAuthenticationProvider. Setting
to false removes those two authentication providers from the configuration.
Then, if the PluggableAuth authentication provider is the only one that
remains, the login page can be bypassed since no user input will be
required. However, if an authentication provider such as a password-based
authentication provider is enabled, the login page is necessary so that the
username and password or other user input can be entered.

Does the OAuth extension require
LocalPasswordPrimaryAuthenticationProvider? That would explain why it only
works if $wgPluggableAuth_EnableLocalLogin is set to true. As far as I
know, there is currently no way to specify authentication providers that
are only available through the user interface versus those that are only
available through the API.



> I am using MediaWiki 1.28.
> I want users to authenticate using OpenID Connect so I have deployed the
> PluggableAuth and OpenID Connect extensions and they are working well.
> I also want to provision accounts in my wiki from another system of record
> using the API and so I have deployed the OAuth extension, created an
> owner-only OAuth consumer, and have written a PHP client against the
> API. It too is working well.
> The issue is that in order for the PHP client to leverage the API and
> authenticate using OAuth AND for users to authenticate using OpenID
> Connect I need to set
> $wgPluggableAuth_EnableLocalLogin = true;
> If I do not set that then the PHP client cannot authenticate using
> OAuth.
> Have I missed something so that I would not have to enable local login
> in order for the PHP client to use OAuth to authenticate and leverage
> the API to provision accounts?
> If not, then I am satisfied with the solution I have except for the user
> login experience. I want them to click "Log in" but not have to then see
> the Special:UserLogin page.
> My thought is to replace that special page with one I create with a
> custom extension that extends the SpecialUserLogin class as suggested
> here:
> Is that the simplest and most elegant approach, or is there a cleaner
> way to "hide" the Username/Password form from users and avoid them
> having to click twice to start the OpenID Connect flow?
> Thanks,
> Scott K
MediaWiki-l mailing list
To unsubscribe, go to: