markdown guide
 

Email.

  • I don't want a bunch of apps to have permissons to my social media accounts.
  • I don't want apps to depend on me being logged in to social media (that's why I've so far never logged into dev.to from my phone).
  • At some point I might want to delete social media accounts for mental health reasons.
  • Plus, if I don't care about the app, I want to be able to use a throwaway address from mailinator to sign up.
 

These are some great points Dustin. Thanks for sharing.

I've also leaned towards using email as well for many services that I use. Mainly because of your first two points.

 

When I choose to use OAuth to sign in it all depends on if I use the services providing the OAuth and if I find them relevant to the website. I will never use Facebook OAuth as I never use the service. I used GitHub over Twitter for Dev.to because I found it more relevant. GitHub and Twitch are two services I'm pretty likely to use for OAuth authentication. If there is no benefit or relevance to using OAuth though, I will usually choose email/password for a website.

 

That's really interesting about using Twitch as an authenticator for a site.

If there is no benefit or relevance to using OAuth though, I will usually choose email/password for a website.

Could you expound on this point Vincent? What do you mean by benefit? Are there any examples you may be able to share about integrations with social that you found useful?

 

Twitch and other streaming services and the applications that interface with them are a good example of the benefits I referred to. Pretty much anything that uses Twitch for OAuth will pull your Twitch API data so that it is able to take information such as your subscribers, subscriptions, followed games/streamers/etc and use it either to enhance the app or to even use the app in the first place.

 

Yes, I prefer OAuth. Think about your audience can't remember password which they created during signup. Also, you don't have to implement app logic for sign up and sign-in process. Also, Big companies maintain the highest security for OAuth so why waste time for creating it focus on business logic.

I recommended you to implement OAuth in your application. OAuth type depends on your audience.

 

Think about your audience can't remember passwords which they created during signup

That's why there are password managers.
I know 99% of time it should be the developers' job to make the users' lives easier, but I think that case fits in the 1% left.

Also you don't have to implement app logc for sign up and signing.

That's called laziness :)

I strongly believe email/password should remain the default and OAuth should only be implemented in addition of it and not instead. Forcing a user to authenticate via another account (social media most of the time) feels like an unnecessary complexity. Some people like their accounts to be independent. Some people dislike social media. Some people might just not have the required accounts to use OAuth. A lot of people have a lot of reasons to dislike (or not be able to use) OAuth.

 

Thanks Sagar and Quentin for your feedback and also thoughtful discussions regarding OAuth and email/password. Everything you both have shared are great points to think through.

 

I prefer OAuth because I'm plain lazy. But I always do so with Google rather than Facebook because I find them to be much more trustworthy and responsible about my data.

I should totally be using a password manager, though, and sign up with email.

 

Allow for either. As had already been stated some users prefer to not have their permissions tied to social media accounts.

Also be aware that some OAuth makes more sense than others depending on the intended use of the application. But most importantly give options for users.

 

I use to prefer OAuth in the beginning.

I stopped after a while. I started disliking the idea of tying all my logins to the major players, this was more or less at the same time I started using password managers.

Notice that most OAuth based websites are either Google Login or Facebook Login.

I still think there's a purpose in OAuth, for example GitHub login makes perfect sense on a site like this one and OAuth is also great for one time passwords.

Ask yourself these questions:

  • are you requiring OAuth just because you don't want to handle the passwords? I've seen websites use OAuth only to fill in email and username but still requiring people to fill in the passwords (and thus I imagine creating a user account that worked on the "local website" with a tie-in to the access token)

  • if you require OAuth are you going to provide an alternative? Even Tinder had to implement a plan B because people didn't trust Facebook with their data

A lot of UI put Google and Facebook in front and center on their signup pages but still provide the possibility to sign up "the old way".

You might also lose customers that don't have social media in the first place...

 

Using OAuth will save you tons of trouble. No need to store credentials in your database, no need to setup a password recovery process, etc.
I was also sceptical first, but as a developer I see many advantages.
Do you know auth0.com?

 

I'll use OAuth if it's the only option, but only if it uses certain services.
Personally, I like there being an email signup option or even - shocker - the option of using the site without having to create an account.

I think it's safe enough to assume that most mature frameworks that offer OAuth logins will also have decent local account options too, so it shouldn't be much extra work.

 

I like the convenience of OAuth, but I prefer to stay away from Facebook for the same reasons as some others have shared here. I liked that Dev.To allowed us to signup with Github and I also like Google signins. I feel like Google and Github are more responsible with my data than some other companies.

 

First, don't use OAuth; use OpenID Connect: oauth.net/articles/authentication

As to whether I prefer OIDC vs mail, definitely OIDC as I won't have to create a new password. BUT only if you don't ask too much things about me: ideally, you wouldn't need anything at all, but asking for my name and possibly profile pic is OK. If you ask for my email address, birth date, or phone number, you'd better have a really good reason, or I'd simply not sign up (BTW, this is one of the things GDPR gets right)

 

I prefer OAuth with the option to choose which data is made public.

For instance Facebook login is very convenient, but I usually don't want to post under my full name. If there is an option to change my displayed name then I am happy.

 

I just configured OAuth2 for my current Rails app 😄 Its a journal app that users will post to via email, so I figured authenticating through Google made sense. It was challenging but fun and best of all - it works! Lol.

 

I like the option of OAuth, but me using or not does depend on the app. For some apps that I don't use often and tend to forget the login info for (like GrubHub or Uber) having OAuth as an option is handy.

If you are building an app, the option of OAuth may attract more people to sign up/register (one less login to remember). At the same time, it can be as an add-on for later (continuous improvement).

 

I prefer OAuth generally. Why? There've been too many data breaches already. If anyone has to have my data, it's better off with a known company with proven security techniques than...some guy. Also, I'm lazy and paranoid about password managers (being on a strange computer and not being able to access my account 😱), so I only use email and password for accounts that are really valuable and run by trustworthy services. Also, OAuth providrs also indicate what permissions you're providing to the application, so they can't do something sneaky behind your back (ideally).

 

Different perspective here: we @ GBG are in the process of moving our business to business applications away from local user identities in each app to a federated solution so our customers can use their IAM solution (typically Azure AD via OIDC), which is a win-win:

  • we no longer have to maintain multiple IAM systems (significant amounts of the codebase in multiple stove pipe products)
  • they retain control of access for individuals through their IAM processes, avoiding having to manage the same identities elsewhere
  • they get SSO for our services.
 

I prefer OAuth for several reasons:

1) It's easier, and I'm lazy.
2) It's more secure. I don't know what kind of attention to security a 3rd party app is taking, but I trust Google and Github to keep my password protected.
3) Probably the most important point for me: I have full control over my accounts. When signing up with an email address, there is no way for me to track which accounts I still have open. I may have forgotten about a service I used several years ago, and it might suddenly get hacked without my knowledge. With OAuth, there is a centralized location where I can see all 3rd-party applications, and revoke access as I see fit. I try to go through all my OAuth dashboards at least once a year and remove access to applications I no longer use, just to be safe.

 
 

Email. I have more control over my email than over any social media accounts, and I'm not giving up my privacy that way.

 
Classic DEV Post from Oct 31 '18

How a Month without Computers Changed Me

I’ve sent a message to my family and delegated my open source projects to my friends. With my last tweet sent, I turn off my laptop, phone, and tablet. My Digital Sabbath begins in 10 minutes: no digital devices for the next month.

Michael Lee 🍕 profile image
Maker of things, giver of high-fives 🖐

dev.to now has dark theme. 🌝

Go to the "misc" section of your settings and select night theme

P.S. You can also change font to sans serif, which a lot of folks prefer. 💖