Jump to content

Topic on Extension talk:WSOAuth/Flow

Trust local logged-in user

5
Summary by Valerio Bozzolan
Valerio Bozzolan (talkcontribs)

Question for User:Xxmarijnw. See this screenshot. I think that if the user is already logged-in in both wikis, we should just trust the account saving it in the wsoauth_users table, instead of treat him/her as a usurper.

Another question. I don't understand how the user (already logged in) says that a central account is his/her.

What do you think about?

Xxmarijnw (talkcontribs)

Hello, thank you for your bug report and my apologies it has been sitting here for so long. Could you describe a use-case where it would be desirable the account is usurped if the user is already logged in locally? If you are already logged in locally, I am not sure if it would be logical/desirable to usurp the account if you logged in again through OAuth. One use-case I can think of is when you do not want to enable automatic account usurpation, but do want to allow existing users to migrate to OAuth when they desire. Is that what you are going for?

Thank you.

Sincerely,

Marijn

Valerio Bozzolan (talkcontribs)

Have you a GitLab account? This kind of websites can have 5+ identity providers but their sysadmins are not involved in any user-per-user verification. That's a great example.

Instead, as far as I noticed, for already existing wikis introducing OAuth, a server sysadmin should manually verify each user to prevent accounts usurpation. This is an amazing feature but the current manual verification workflow is not feasible because:

  • manual verification activity takes time
  • every hour of a server sysadmin costs ($$)
  • it's somehow hacky (contact each user via Special:SendEmail via both wikis or something like that?)
  • this can be the cause of human errors and social engineering
  • this is not the real-world workflow

Well, instead, this could be the workflow:

  1. user Foo logins into the local website with an already trusted method (like legacy credentials) - refusing other methods of course
  2. user Foo navigates in preferences
  3. user Foo clicks on connect your profile to AwesomeSocial
  4. (user Foo triggers authentication into AwesomeSocial)
  5. thank you! Now you are verified and next time you can quick-login via AwesomeSocial
  6. user Foo organizes a really hard party 🎉

Now. Instead of a brand-new preferences page, for now we can just trust an user already logged-in locally if she/he is able to complete an authentication from her/his favorite identity provider. From that moment, she/he can use that identity provider for future logins.

What do you think about?

Xxmarijnw (talkcontribs)

Hello,

Again, apologies for the wait. I think this would be a nice feature to add to the extension. I will add it once my time allows it.

Sincerely,

Marijn

Valerio Bozzolan (talkcontribs)

Just for transparency, I contacted you in private via email yesterday and, thanks to your quick response, probably we have found an investor.

To speed up the process I tried to describe this feature in phab:T283908. Feel free to edit whatever you want. See you in the next days :)