Closed kognise closed 5 years ago
This issue is on the roadmap, which means we will get to it after our MVP. I will close this issue for now so we can focus on resolving our non-roadmap issues first.
For those who missed it. Here are the Nov 15th meeting decisions on an MVP for authentication, which is just a Google login integration to start.
Quincy put this conversation on the roadmap for after an MVP.
This conversation was continued at #305
Also, the use of "SSO" above is likely not in the context most were thinking.
The ability for a user to authenticate using their Google account is apparently using OAuth 2.0, and SSO / SAML is a different enterprise use case.
Chat from today's Chapter meeting.
Mihir Somani 2:29 PM You mentioned that one of the benefits of using OAuth with social media is that it allows users to share the information about chapters/events easily since we already have the "details" of the social account. But, I believe for this reason, we need to add support for Facebook OAuth as well since Google doesn't really have any popular social media platforms. Quincy Larson 2:30 PM Mihir thanks for your feedback. We may add Facebook auth in the future but Google Auth is the natural option because it has integrated calendar, and people are much more willing to create new gmail accounts than new Facebook accounts. Saritta Hines 2:32 PM I think using Facebook with OAuth has a negative connotation associated with it..as far as sharing data etc...Twitter would be a better option imo than FB Mihir Soman 2:33 PM I believe it's better to have both. passport.js is an amazing library which lets us add OAuth policies very easily and smoothly.
The main problem with having multiple auth options is people forget which one they used, and they often have different email addresses associated with different social media accounts. Passport is smart, but it isn't psychic.
The correct number of authentication options to offer is 1. freeCodeCamp made the mistake of offering many, and ever since then we get emails from angry people saying we lost their data when in fact they just accidentally signed in using a different social auth provider and created a duplicate account.
From a UX perspective, we probably want to make the experience for users who just want to RSVP to events as streamlined and possible. One thing that imo should be considered is user account management. With the current design, users have to create and manage separate accounts across all Chapter instances they're signed up to. This could get tedious.
I think we should have a conversation about possible solutions to this, I'm not very experienced with decentralization in general but I think we could implement some sort of SSO. This would also enable syncing user account details and interests across instances.
One network that solves this exceptionally well is Stack Exchange - we could look into how they do this. I haven't done a lot of research but I think they use something OpenID-related.
I'm open to learn new things!