Page MenuHomePhabricator

Integrate with OAuth
Closed, DeclinedPublicFeature

Description

Integrating with OAuth would allow authentication without storing and managing passwords in the application. There would probably still be a need to manage authorization within the application.


Version: wmf-deployment
Severity: enhancement

Details

Reference
bz72292

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:52 AM
bzimport set Reference to bz72292.
bzimport added a subscriber: Unknown Object (MLST).

Notes from an email conversation:

@bd808 wrote:

@Nehajha wrote:

@bd808 wrote:
Grants is a little different. The current user account system handles both authentication (who are you) and authorization (what are you allowed to do). OAuth can really only replace the authentication portion of this. That means that OAuth can act as a functional replacement for providing your username and password to the application. It would do this by allowing an OAuth account to be associated with an existing local account. The login workflow would change to look something like the way that Phabricator logins work. The login screen would still have the username and password prompts but would also have some kind of "login with OAuth" button that could be used instead. When the OAuth handshake completes then the backend system would look for an existing local user account associated with the Wikimedia account that just authenticated and load it as though the username and password for it had been provided.

So the workflow for Grants app user account system would be -

  1. User logs in using local account
  2. The user has an option of associating a wiki account with her local account so that in future she can log in using this wiki account.
  3. Save these OAuth details to relate the local username and password with the user
  4. When the user logs in using OAuth, check if any user exists in the application having these credentials.

The association will be done by the user only once. For removing the association, the backend will delete the OAuth credentials associated with that user. So that the user can no longer use her wiki account for login.

That sounds right to me. All you need to store in the local user is the SUL username or SUL id. The OAuth token data that you get back from the OAuth handshake is only needed to make the Special:OAuth/identify call (https://www.mediawiki.org/wiki/OAuth/For_Developers#Identifying_the_user) immediately after the handshake. Then you lookup the local user using the SUL username or id from the user that you just authenticated and if there is a match you load that user record. If no match is found you just tell the user that this account is not registered.

Nehajha added a revision: Restricted Differential Revision.Dec 22 2017, 2:43 PM
Aklapper subscribed.

@Nehajha: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:12 AM
Aklapper removed a subscriber: wikibugs-l-list.

Declining as the application is not in use anymore per T351889