What user authentication methods do we need in the MVP?
- Stack Exchange OpenID
- Specific social network associated accounts (Google, Facebook, etc.)
- OpenID or OpenAuth from arbitrary providers
What user authentication methods do we need in the MVP?
I’m no expert on this, but I believe we should have a username/password system here, in addition to any other 3rd-party (SE, Google, Facebook, etc.) associated login. That is for a number of reasons, including:
I think MVP needs two methods:
Not MVP, but nice if easy to do: common identity providers such as Google, Facebook, etc.
MVP if we want to migrate Ask Ubuntu: launchpad.
Not MVP: second authentication factor.
I think this depends on what gets launched initially for MVP.
If you’re talking about a Q&A site which doesn’t require or rely on anything personally identifiable, then OpenID/common identity providers would be enough.
If you’re talking about a Q&A site which does require or rely on something personally identifiable, then that gets trickier since all OpenID/common identity providers tie to real-ish identities. Passwords would be good here too.
I’d really not rather y’all get in the business of storing passwords, though.
If we are talking about creating our own auth system - id probably venture towards SSO. Create our own IDP, we can then set up the site as an SP and use the same auth code for any number of IDPs - first or third party.
Keep It Simple.
Usernames/passwords are the simplest authentication method, both to use and to create. Storing passwords is not a difficult thing to do, as long as you’re aware of best practice. There are some technical decisions to be made there that I’m happy to advise on, but there are so many arguments in favour and so few arguments against using user/pass that we’d be silly not to offer it.
Agree with @gilles - user/pass and SE auth for MVP.
With an own SSO server, what looks like ordinary User/Password identification to the user might in reality be an authentication with the SSO server.
So what benefit does it offer us over standard user/pass, @celtschk? Bear in mind that implementing an SSO server adds significant work to the project, beyond what would be required for basic user/pass. If there are significant advantages, it may be worth it; if not, it can’t be MVP.
@ArtOfCode probably the biggest advantage of creating an independant IDP via SSO or (more realistically) OpenID is separating user data from application data.
It would allow us to scale and use the same user data across different apps in the future. That would work quite well if Codidact starts splitting up across different servers or if we want to start thinking about native/mobile apps.
It is more work though although there are tools out there such as openSamlPHP and openSamlJava where creating an IDP can be more achievable as the complicated parts of the process are abstracted.
In that case, @mattjbrent, it’s something we should look into after MVP. The quicker we have a product available, the better; more work is kinda the opposite of that, but the benefits do make it worth doing after that.
IMHO working out how to handle identity as far as we can should be part of the MVP.
There are just so many things relying on it, adjusting it later will be a huge hassle.
Let me argue against doing our own identity handling - especially passwords - though:
It’s not that it’s impossible or even exceptionally difficult.
It’s just that it’s very easy to do something wrong.
Maybe right now we do have among us the know-how to do it right,
but can you guarantee their standards will be upheld after they left?
Because a lot of “common sense” things in programming don’t apply to crypto.
If somebody messes up the answering process in the future, meh, it’s a bug and we fix it.
If somebody messes up our own password handling, it might be our fault (ethically) that attackers manage to log into someone’s bank account (credential reuse is still rampant).
My suggestion would be to use something like IdentityServer.
I don’t think IdentityServer would be easier/faster than handling a simple user/pass login system. Yes, it’s easy to mess up which is why we have to do it right.
But we need to launch as fast as possible. And most people know/are familiar with a simple user/pass setup. For MVP it sounds like user/pass and SE tie in are the way to go.
And the key on user/password is to (a) salt/hash appropriately (easy and well-documented these days, but if you’ve never done it then it can be confusing) and (b) minimize the time & places that the original password “exists”. Not rocket science, and unlike 20 years ago, there are well established patterns & good libraries to use.
I don’t think IdentityServer would be easier/faster […] But we need to launch as fast as possible .
No, it will be more proper. As fast as possible would be storing passwords in clear text.
The only way to go fast is to go well. Identity is the one thing that pretty much every use case we have is built upon. It’s the one place we should not cut any corners.
Yes, it’s easy to mess up which is why we have to do it right .
Or we just take something that is already done right in all points.
And most people know/are familiar with a simple user/pass setup.
Sure, in the 90’s we all used usernames and passwords, and we all still know how that works. At the moment, that’s “oldschool”, but it’s already in the process of losing the “-school” part. TBH, it’s probably already the opposite of impressive for gen Z.
If you’re wanting to use Stack Exchange as an authentication provider then it seems to me like you get the most bang for your buck by picking an off-the-shelf self-hosted authentication provider that speaks the same protocol.
There hasn’t been recent activity here. Is there a consensus? Could somebody summarize it if so?
I think the problem with not starting with a secure method is that porting to a better one later is a lot of effort, as we would have to get users to reauthenticate with the new system. I’m not at all familiar with authentication so I could be completely wrong though.
IMO, the most secure system we can have is MVP. It means that at a later date we won’t have to do as much maintenance/upgrading on low-quality systems thrown together in a short amount of time.
It’s possible to authenticate with the old system, but have the client remember the password so that after the old system authenticates the user the client automatically registers with the new system (and marks that user as using the new system). This is a pain because you have to maintain both systems for an indefinite period of time.