User authentication methods in MVP

What user authentication methods do we need in the MVP?

  • Passwords
  • Stack Exchange OpenID
  • Specific social network associated accounts (Google, Facebook, etc.)
  • OpenID or OpenAuth from arbitrary providers
1 Like

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:

  • Some users may want to use a throwaway account for confidentiality reasons (especially in sites like IPS and Workplace)
  • Some users feel more secure with not connecting too many pieces of their online life
  • Some users may not have any other compatible accounts (I have actually had this problem on some sites where they seem to encourage signin via “other stuff” and have no obvious “new account” mechanism - I leave those sites and don’t come back).
    And on the other hand, some people who really don’t care much about these issues will prefer a single signon based on one of the biggies - e.g., Google, Facebook.
    That being said, MVP includes create and manage internal accounts. If a new user comes in and we don’t have Google/Facebook/SE working, they can read without requiring any login and if they really want to ask a Q then they will create an account.
5 Likes

I think MVP needs two methods:

  • Passwords are necessary because not everyone wants to tie their account to a third party. They’re the only authentication method which is easy to use and doesn’t require a third party.
  • Some method that makes it easy for people to tie their account to Stack Exchange. This is in MVP because we want to make it easy for people to migrate from Stack Exchange.

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.

5 Likes

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.

1 Like

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.

4 Likes

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.

1 Like

@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.

1 Like

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.

2 Likes

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.

3 Likes

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.

3 Likes

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.

3 Likes

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.

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like