Integrating OAuth with MediaWiki for Enhanced Security

Why OAuth Matters for Your Wiki

Picture this: a colleague clicks a link, a pop‑up asks for Google credentials, and—boom—your MediaWiki knows exactly who that person is. No more “anonymous vandal” headaches, no more “who‑did‑that‑edit?” mysteries. In the wild world of content collaboration, OAuth isn’t just a buzzword; it’s the sturdy lock on the front door.

Recent headlines have reminded us that password‑reuse is a ticking time‑bomb. When the same secret lands on dozens of sites, a single breach can cascade like dominos. Relying on plain‑old username/password combos is about as safe as a paper crane in a gusty gale. By offloading authentication to trusted identity providers, you sidestep the whole “store‑and‑protect passwords” nightmare.

Picking the Right Extension

MediaWiki doesn’t include third‑party OAuth/OIDC login out of the box. You’ll need a little plumbing, and the most battle‑tested combo today is Extension:PluggableAuth paired with Extension:OpenID Connect. Together they let you speak the OIDC language that Google, Azure AD, and many other IdPs understand.

Both extensions are solid, but if you want a “plug‑and‑play” feel with minimal custom code, this duo usually wins the day.

Step‑by‑Step: Installing PluggableAuth + OpenID Connect

Run the three commands below, one after the other. They’ll pull the code, tell MediaWiki to load the extensions, and bring the database schema up to speed.

Action	Command
Install via Composer	composer require mediawiki/pluggable-auth mediawiki/openid-connect
Enable extensions	wfLoadExtension( 'PluggableAuth' ); wfLoadExtension( 'OpenIDConnect' );
Run DB updates	php maintenance/update.php

That’s it for the heavy lifting. Now the real work begins: telling MediaWiki how to talk to Google (or whichever provider you prefer).

Configuring Google via OpenID Connect

Paste the snippet below into LocalSettings.php. Adjust the client ID/secret you got from the Google Cloud console. The array key is the issuer URL; it can be swapped for Azure AD or any other OIDC‑compatible IdP.

// Load the extensions (if you haven’t already placed the wfLoadExtension calls above)
wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'OpenIDConnect' );

// OpenID Connect configuration for Google
$wgOpenIDConnect_Config['https://accounts.google.com'] = [
    'clientID'     => 'YOUR_CLIENT_ID',
    'clientsecret' => 'YOUR_CLIENT_SECRET',
    'scope'        => [ 'openid', 'email', 'profile' ],
];

// Optional: tweak the login button label
$wgPluggableAuth_ButtonLabel = 'Sign in with Google';

// Optional: keep the traditional local login form available
$wgPluggableAuth_EnableLocalLogin = true;

Save the file, then clear caches the “proper” way: either run the localisation cache rebuild or simply purge a page you’ve edited.

// Rebuild localisation cache – forces MediaWiki to reread settings
php maintenance/rebuildLocalisationCache.php --force

Or, from a browser, add ?action=purge to a URL you know is cached.

Fine‑Tuning Permissions

OpenID Connect gets a user inside, but you still decide what they can do. MediaWiki’s $wgGroupPermissions array is where the magic happens. Here’s a quick baseline:

// Everyone can read (default)
$wgGroupPermissions['*']['read'] = true;

// Authenticated users can edit, but not delete
$wgGroupPermissions['user']['edit']   = true;
$wgGroupPermissions['user']['delete'] = false;

// A “trusted” group for power users
$wgGroupPermissions['trusted']['delete']  = true;
$wgGroupPermissions['trusted']['protect'] = true;

By default, OIDC‑authenticated accounts land in the regular “user” group. If you want to auto‑promote certain users (say, staff accounts), you can write a small hook that checks a claim like groups and adds them to “trusted”.

Handling Edge Cases (and the occasional glitch)

OIDC isn’t a silver bullet; it has quirks. Tokens do expire, and refresh‑token handling is baked into the OpenID Connect extension. You don’t need to manually splice &prompt=none onto the auth URL—just let the extension do its job. If you see “session expired” pop‑ups during an edit, check two things:

• Is the provider issuing a refresh token? Some IdPs require you to enable the “offline_access” scope.
• Do you have https everywhere? Mixed‑content warnings can silently kill the token‑refresh AJAX call.

When in doubt, the extension writes helpful messages to debug.log. Turn on debugging in LocalSettings.php if you haven’t already:

$wgDebugLogFile = "/path/to/mediawiki/debug.log";
$wgDebugRawPage = true;

Testing, Testing, 1‑2‑3

Before you open the doors to the world, spin up a sandbox. Create a dummy Google OIDC client, set the redirect URI to:

https://yourwiki.example.org/index.php?title=Special:PluggableAuthLogin

Then try a couple of logins. Keep an eye out for these classic hiccups:

• Missing email claim – you’ll end up with an “anonymous” account because MediaWiki can’t map a username.
• Scope errors – Google will reject the request if you forget openid email profile.
• CSRF/nonce mismatches – the OpenID Connect extension automatically validates state and nonce; a mismatch usually points to a bad client secret or an outdated configuration.

When everything clicks, you’ll see a friendly “Welcome, your‑name!” banner at the top of the page and the usual edit links appear (no neon‑green buttons required).

Keeping Up With Provider Changes

OIDC isn’t a set‑it‑and‑forget‑it system. Providers rotate signing keys, deprecate endpoints, and sometimes add new claims. A good habit is to subscribe to the provider’s developer newsletter (Google’s “API Updates” mailing list, for example) or watch their status page. When a new jwks_uri appears, the extension will pick it up automatically on the next request.

Beyond Google: Azure AD and Other OIDC Providers

If you’re in a Microsoft‑heavy environment, Azure AD works just as smoothly. Swap the issuer URL and client credentials, like so:

$wgOpenIDConnect_Config['https://login.microsoftonline.com/common/v2.0'] = [
    'clientID'     => 'AZURE_CLIENT_ID',
    'clientsecret' => 'AZURE_CLIENT_SECRET',
    'scope'        => [ 'openid', 'email', 'profile' ],
];

Replace “common” with a specific tenant ID if you want tighter control over who can log in.

When OIDC Isn’t Available

Some services (GitHub, for instance) only expose a pure OAuth 2.0 flow without the OpenID Connect layer. In those cases, point readers to the Extension:OAuth2 Client, which knows how to handle plain OAuth 2.0 token exchanges and can be paired with PluggableAuth for a consistent login experience.

Prerequisites and Security Hygiene

Before you start, make sure you’ve checked off these basics:

• Your wiki runs over HTTPS. Both the IdP and MediaWiki will refuse to exchange tokens over plain HTTP.
• The “Authorized redirect URIs” list in the IdP console exactly matches https://yourwiki.example.org/index.php?title=Special:PluggableAuthLogin.
• You’re on a recent MediaWiki version (1.39 or newer) and PHP 7.4+; older stacks may hit compatibility snags with the extensions.
• Consider enabling $wgSecretKey rotation and regular backups of LocalSettings.php. Losing the client secret is a pain you don’t want to feel.

Wrapping It All Up—Sort Of

So, what’s the take‑away? OpenID Connect via PluggableAuth is like installing a security camera on your wiki’s front porch: it tells you exactly who’s at the door and keeps strangers from slipping in unnoticed. The integration boils down to a few Composer commands, a tidy LocalSettings.php block, and a dash of permission tweaking.

Remember, security isn’t a one‑time checkbox; it’s a habit. Keep an eye on token lifetimes, stay subscribed to provider announcements, and audit who’s roaming your pages. A well‑guarded MediaWiki isn’t just safer—it’s a happier place for contributors to share knowledge without looking over their shoulders.