Install MediaWiki OAuth extension on noisebridge.net

[nthmost-orkes]

What

Request to install the MediaWiki OAuth extension on the wiki.

Why

Two projects would benefit from this:

Meeting Notes Tools

Right now the meeting notes automation posts as a bot account. With OAuth, the person who actually processes/publishes the notes could authenticate and have the edit attributed to them. Same for any future admin panel — we'd want wiki admins to log in as themselves rather than sharing credentials.

Quest Board (nbquest.nthmost.net)

The quest board prototype currently uses the wiki's action=login API directly, which means users type their wiki password into our app. Not ideal.

With OAuth, users authenticate on the wiki itself and grant the app permission. When someone creates a quest or marks one complete, the app could also update the relevant guild's wiki page — attributed to that user, not a bot.

Technical bits

• Extension: https://www.mediawiki.org/wiki/Extension:OAuth
• Wiki is on 1.39.13, which supports it
• Supports OAuth 1.0a and 2.0
• Python library: mwoauth
• Consumer registration happens at Special:OAuthConsumerRegistration

Related

• Auth system - for rack watchers - grafana, anonymized logs, etc #498 (auth system discussion)
• Process for getting access to http://auth.noisebridge.net/ and associated services #477 (auth.noisebridge.net access)

Happy to help test once it's installed.

[nthmost-orkes]

To clarify what's currently possible vs. what OAuth would enable:

What we can do now: action=login API

MediaWiki's built-in action=login API lets apps verify wiki credentials:

1. User types username + password into the app
2. App forwards credentials to noisebridge.net/api.php?action=login
3. Wiki validates and returns success/failure
4. App stores username in a session cookie, discards password immediately

This is what quest-board currently uses. It works, but:

• Users must trust the app with their password (even briefly, in memory)
• No granular permissions — it's all-or-nothing identity verification
• Group membership requires extra API calls — checking if someone is a sysop means a separate action=query&list=users&ususers=X&usprop=groups request
• No revocation — if a user wants to "log out" of all apps, they'd have to change their wiki password
• Password exposure risk — any app using this pattern sees the plaintext password, even if only momentarily

What OAuth enables

• User authenticates on the wiki itself — password never touches third-party code
• Granular grants — app can request only what it needs (read profile, edit pages, etc.)
• Group info in the token — the identity JWT includes groups so admin checks are trivial
• Per-app revocation — users can revoke access to specific apps at Special:OAuthManageMyGrants
• Standard pattern — same flow users see on GitHub, Google, etc.

For internal tools we control, action=login is workable. But for anything user-facing where we're asking people to type their wiki password into a non-wiki site, OAuth is the proper solution.

[nthmost]

ugh, this is why is shouldn't use my work laptop interchangeably w/ other things

A few words about the above:

• no real pressure (time or otherwise) to do this
• no "absolute need" in terms of functionality i'm trying to build, just "nice to haves"

and I'm curious if this has been discussed before.