Decide on Auth system

[gideonthomas]

We're trying to decide on what auth strategy to use for the network-api and for our CMS work in general. It would be good to consolidate our Auth strategy across our CMS implementations.

Our current thought is to use Github authentication here.

Rationale for Using Github

• Allows us to manage permissions for existing staff using the Github Mozilla org's teams to assign who has access to what
• Allows us to easily add contributors and assign permissions based on the org teams

Network Pulse uses Google Auth instead. We would like to understand the rationale behind choosing that for the pulse api as well as understanding the pros/cons of using google auth vs. github auth vs. something else.

[simonwex]

@xmatthewx @Pomax @mmmavis it's key to use the same strategy moving forward across our content editing tools. Do you have any thoughts? It's my understanding that it would be technically simple to swap google for github in our current implementation.

[Pomax]

Is there a good reason for not going with "all common social logins" so we get github for free because those already cover google, github, facebook, twitter, etc.?

[xmatthewx]

My preference would be for google or all common social logins. Is there a user case for Github? Short-term, google is easy since all staff have it. MId-term, we aim to have non-staff users who do not work with software (a policy fellow, a thought leader), who post to Pulse and potentially craft simple landing pages for an initiative.

BTW: I love login auth stuff. Like croquis and daffodils popping up, it's how I know it's Spring time. 🌷 🥀

[simonwex]

The win for using Github is solely that we manage our contributor's access there currently–we use Github for content other than code. If we're commonly going to have users that do not have a Github account, I'd also vote for Google.

I'd vote against the "Nascar login" (all social providers) as users forget which service they use for what.

[Pomax]

Nothing wrong with opinionated nascar: prominent "Click here to log in with github" text and button, with a subtext and link "or click here to see more login options" that reveals the other, less preferred, options. I've seen a fair few sites do this, and it works as a nice funnel. Having said that, this suggests an obvious iterative process where we first set up github login, and then in follow-up add in the additional login options.

The one thing I'm worried about is that we're going to keep doing the same thing when it comes to login, which is saying we want to offer a good login experience, but then pick a single login solution and taking a year to discover all the ways in which that particular solution actually falls short for the people we want to actually have use our service(s). Obviously we're balancing "we need to deliver a thing" against "we want a great solution", but I'd like to keep playing devil's advocate and say "let's go for offering lots of different logins anyway", even if we don't end up there =)

[xmatthewx]

Nothing wrong with opinionated nascar

I'm down with an aspiration for an opinionated nascar.

If we're commonly going to have users that do not have a Github account, I'd also vote for Google.

I vote we start with Google and ask Kristina to gather a few benchmarks for "View more login options". I recommend we keep design investment light until we have secondary options in development.

[gideonthomas]

@simonwex, what's the verdict on this?

[gideonthomas]

@simonwex re-pinging about this. Does this need to be a part of MVP?

[simonwex]

For MVP let's use built-in auth flow. There aren't so many that it'll be a serious task to input them manually.

I've filed this: https://github.com/mozilla/network-api/issues/92