Use 3rd-Party Authentication Providers

[ariutta]

To simplify our infrastructure, let's move away from handling authentication on our own. (Authentication is "who are you" and authorization is "what are you allowed to do".) We will still need to have user accounts and handle authorization, but we can delegate authentication to 3rd-party authentication providers using many different technologies. We might also still need to support authentication for existing users.

Companies wanted to create a standard to allow other sites to offer "Sign in with Google/Twitter/FB" buttons, but there's been quite a bit of evolution in this area, and the names of the systems for doing this are confusing:

• OAuth 1.0a: had a complicated signature system in order to work on both HTTP and HTTPS
• OAuth 2.0: superseded OAuth 1.0a, dropped signature system and requires HTTPS
• OATH: something else very different from either of the above
• OpenID: an early system, very cool, but didn't get enough buy in and is dying
• OpenID Connect: very different from the similarly named "OpenID". Is based on OAuth 2.0, with additional things like JWTs in order to handle authentication

Which authentication provider(s) should we use? In addition to the big names like Google/Twitter/FB/GitHub, there are also these two options:

Single Sign-On with Wikipedia

The OAuthAuthentication extension allows for authenticating against a remote wiki. We can register WikiPathways as an app on meta.wikimedia.org to use Wikipedia as the remote wiki. This is "a somewhat OpenID-like custom protocol for determining user identity".

ORCID

It appears to be using OpenID Connect?

[ariutta]

If we want to use any OAuth 2.0 provider, this MW extension is a client.

[ariutta]

Even better, this MW extension is an OpenID Connect client.

[ariutta]

@egonw did you know of an ELIXER option or anything else you were recommending?

[hexmode]

I think this is the ELIXIR integration information

[hexmode]

So, the question is: which one do you want? Or do you want all the authentication?

[ariutta]

I really would like to use Wikipedia for this. ORCID and/or ELIXER would be nice to have. No strong opinion on the others. @AlexanderPico @egonw @mkutmon any opinions?

[AlexanderPico]

For our typical user, I think Google and LinkedIn would be the more common prior accounts by far. Then maybe ORCID? Wikipedia makes sense (like, their both wikis), but I don’t actually think most of our contributors have ever edited or created accounts on Wikipedia before. And ELIXER is mostly politics, I presume :)

[egonw]

I think Google would be very valuable to have. I'd prefer ORCID over LinkedIn (I see students rather get an ORCID than a LinkedIn account)... ELIXIR is europe-centric (https://www.elixir-europe.org/services/compute/aai-overview), but has the advantage that the authentication will integrate with the core facilities (think EBI database, Uniprot, Human Protein Atlas)...

[nunogit]

ORCID allows OAuth as well. We can actually have 2 or 3 ways of doing it (ORCID, Google, other?) Without doing any further investigation I have a concern: considering that we still have an old mediawiki, do you think this the moment to do it? We will probably have to use old code / plugin to achieve it, not?

[egonw]

@nunogit, no worries regarding your concern: this is the wikipathways-upgrade-2017 tracker...

[hexmode]

Keep in mind that you're doing this partly to combat spam. With that in mind, Google, Wikipedia, and LinkedIn authentication should be out since any anonymous person can get them.

ORCID and/or ELIXIR seems best.

Finally, it would be possible to open up account creation completely but restrict edits to those who you explicitly authorise or who have their account tied to an outside identity.

[AlexanderPico]

Let's not go too far here... I'm not worried about humans creating Google accounts and then signing up at WikiPathways to vandalize the site. The (minor) activity we're seeing is a few bot accounts clearly designed to populate Mediawiki pages with links. In fact, the two most recent (and only two we've seen in many years) specifically populated the registered email field with a spam domain. So, any third-party solution would solve the problems we are seeing. I don't want to solve all possible spam problems; just the ones we are seeing :)

Based on this, I'd like to support the account types that present the lowest possible hurdle to legitimate contributors. Keep in mind, that are largest problems are the hurdle for new contributors, not spam.

I'm totally fine with ORCID and ELIXIR, but our solutions must also include accounts that our potential contributors are likely to already have, e.g., Google.

[ariutta]

If we support Google, I vote to also support GitHub and Twitter (if the extra effort required is minimal).

So we have a few different use cases:

• Normal login
  • Existing users
  • No changes required (we still support their current username/pwd login)
  • Can optionally tie one or more of their 3rd-party accounts to their WikiPathways account?
  • What about existing users who have never made an edit?
  • New users
  • Must use a 3rd-party authentication provider (username/pwd login not allowed)?
  • 3rd-party auth required for making edits (as per @hexmode above)?
• API auth for making edits
  • For browser JS
  • For non-browser client libraries like wikipathways-api-client-py

[hexmode]

Hopefully we can prioritize this next week while I'm there.

[Chris-Evelo]

Not urgent, but in the longer run we could consider also to support the ELIXIR AAI (assuming they want to support us)

[ariutta]

@hexmode, when I suggested this, my goal was to reduce our maintenance burden. But do you think it would actually simplify things considering we still need to support our own authentication for existing accounts?