Full user auth

[scottgonzalez]

The more I think about it, the riskier it seems to solely rely on external auth. We should have full auth built-in, but for simplicity we can probably avoid creating passwords based on which auth module is in use. I'd like to try to continue delegating to GitHub OAuth and generate a user without a password. But if GitHub is down, the user should be able to create a password (through a normal password reset flow), and log in through an actual form.

[jaubourg]

Seems a bit overkill. Relying on GitHub OAuth seems good enough to me, given GitHub's high availability and business-incentive to fix problems as fast as humanly possible. The only problematic situation would be if GitHub was to shut down, which I think is unlikely in the foreseeable future.

Beside, by the time the user generates a password and receives the confirmation mail, GitHub will probably be up again.

[scottgonzalez]

GitHub is just one auth provider. Also, people say the same thing about Google, and there have been multiple occasions where Gmail was unavailable for hours.

[jaubourg]

I dunno, I find it very confusing to users for very little gain. What's so critical about a but tracker availability? If a provider associated to our repos is down, won't we have some problems actually fixing bugs? I'm not saying it doesn't make some sense, I'm trying to gauge if it is worth it.

[scottgonzalez]

You need to stop thinking about tight integration between GitHub and DEBT. DEBT will ship with lots of integration, but it won't be core to how DEBT works. You can opt for any other auth provider, you can host code on other sites, etc.

[jaubourg]

I understand that perfectly and it doesn't invalidate my concerns.

[scottgonzalez]

Does this invalidate your concerns? https://twitter.com/shamblepop/status/415435651283042304

[jaubourg]

No it doesn't. It just means a site should support multiple OAuth and allow people to attach several of them to the same account, not that it needs an ad-hoc, confusing, unnecessary password generator. The conclusion is that you need to be able to sign in as the same user using several different OAuth providers, not that DEBT needs to re-invent the wheel poorly. AFAIK, that's how StackOverflow works.

[scottgonzalez]

I don't know how having standard user authentication is poorly reinventing a wheel.

[jaubourg]

Am I supposed to answer this?

Let's see, right from the start you take the specific example of GitHub as a provider then you slam me for using the same example. I answer I still think there is a cost/gain ratio to determine regarding how often and how long a OAuth service may be down, you act as if I didn't understand your first reply. I tell you it doesn't matter if we're talking specific provider or not, you link to a twitter message talking about an OAuth provider shutting down (not being down temporarily, plain shutting down). I then try and explain what I believe is the actual problem here and you ignore the reply except for the, admittedly snark, remark which you take out of context using the word "standard" in its most vague acceptation.

Are you certain you want feedback on this project? If not, let me know straight and I won't bother you anymore.

[scottgonzalez]

I didn't slam you at all. You were making a tight association between GitHub and DEBT (if we can't write code, why do bugs matter?). I also pointed out specific examples of high availability service providers being down for long periods of time and auth providers shutting down. Both of which I consider to be extreme problems. A DEBT instance should not become unusable because of issues with an external provider.

I must have missed the part where you said it doesn't matter if we're talking about specific providers. I honestly still don't see where you said that. The closest I see is "I understand that perfectly and it doesn't invalidate my concerns." to which I pointed out a recent example of someone not being able to access a site because their auth provider shut down. Similarly, I see "What's so critical about a but tracker availability?" When all you do is bug tracking, availability of the bug tracker is pretty critical.

I assume the comment you think I'm ignoring is "The conclusion is that you need to be able to sign in as the same user using several different OAuth providers, not that DEBT needs to re-invent the wheel poorly." I've said this before and I'll say it again: Supporting multiple auth providers simultaneously is terrible UX. Users get confused about which provider they chose in the past and it just leads to frustration.

[rxaviers]

What if DEBT supports both oath and regular password authorization and let user to decide what balance of convenience vs. availability he wants. In other words, user could decide which methods to authenticate. For example:

User could authenticate via github only, therefore choosing convenience over availability. Or a user could decide to authenticate via several different supported oauth providers (eg. github, google, facebook?, etc), plus via the regular password authentication, therefore choosing availability over convenience.

[scottgonzalez]

Ultimately the authentication system will be fully pluggable, so users can choose whatever they want.

I was actually just thinking about this the other day, when I remembered an idea that @arschmitz had. Instead of having a full auth system, just use one-time links that get emailed out. Essentially the same process as a standard password reset, except instead of setting a new password, you're just logged in. Then we don't need to store passwords at all.