Ask HN: Ok to only allow Google/Apple/FB login for mobile app?
11 comments
You can do that. It's your app, your rules. And doing that might be easier than setting up email/password authentication.
That said, whenever I encounter a site or app or service that only supports so-called social login I give it a pass. Mainly because I don't have an account with most (if any) of those kinds of services. I might be a weird outlier, but I'm sure I'm not alone.
That said, whenever I encounter a site or app or service that only supports so-called social login I give it a pass. Mainly because I don't have an account with most (if any) of those kinds of services. I might be a weird outlier, but I'm sure I'm not alone.
I'm in the same camp. Even though I still keep my google mail just in case I forgot to tell somebody I'm not using it anymore. Same with FB - I was kicked out after I refused to send FB a scan of my ID.. So service which does not allow me to log in with my own email would automatically rule me out.
Would avoid like the plague - nobody in their right mind should use such "social logins" as it not only leaks more of your personal data to these services but more so because if BigTech denies you access for whatever reason, you lose access to all internet accounts linked to such logins.
I never use "social logins" because I don't know what the implications are. I feel like I do know for email/password.
Me too. I have no social media accounts I could use, but if I did, I certainly wouldn't use them to log into anything other than that particular social media service.
Just adding my voice to the chorus and adding that I too won't use apps that require a social login.
I thought I was the only one...
I also avoid sites that only have social login. Don't think it is odd at all.
> I'm working on a food ordering app.
Just use SMS (enter phone number, text me a code, enter the code). They'll need to provide a phone number for the food provider or deliverer to contact them anyway.
> Password managers may or may not work in an app.
Password managers work fine with apps.
> Implementing password auth (as well as registration, password-reset/etc) is not trivial.
You absolutely shouldn't roll your own user management or authentication at this point. It's extremely difficult to write such a system securely from scratch, and there are a million SaaS products that do it.
Auth0 is respected, well-known, and not expensive[1]. The admin UI for devs is sometimes annoying, but their support is excellent and free.
> Do I need to authenticate users at all?
...Maybe. You need some way for users to recover their order history if they lose their phone, for example. Perhaps there's a way you can get a unique identity through the Stripe process, not sure.
1. https://auth0.com/learn/two-factor-authentication/
Just use SMS (enter phone number, text me a code, enter the code). They'll need to provide a phone number for the food provider or deliverer to contact them anyway.
> Password managers may or may not work in an app.
Password managers work fine with apps.
> Implementing password auth (as well as registration, password-reset/etc) is not trivial.
You absolutely shouldn't roll your own user management or authentication at this point. It's extremely difficult to write such a system securely from scratch, and there are a million SaaS products that do it.
Auth0 is respected, well-known, and not expensive[1]. The admin UI for devs is sometimes annoying, but their support is excellent and free.
> Do I need to authenticate users at all?
...Maybe. You need some way for users to recover their order history if they lose their phone, for example. Perhaps there's a way you can get a unique identity through the Stripe process, not sure.
1. https://auth0.com/learn/two-factor-authentication/
1) Can? I think so. Should? I’m not too sure. Obviously, there are people who don’t have those “social” accounts or don’t want to use them even if they’ve somehow signed up for one. The big question though is not their existence, but their numbers in the potential user base.
By removing adoption friction for one group, you are potentially adding a friction point for another. You’ll have to be the judge on whether it’s worth it.
How about email-only passwordless authentication? Seems like a viable alternative to the username/password. And yeah, keep the social logins as well on top of that.
2) Yeah, that necessity depends on your product.
In what cases or features is authentication needed in a food-ordering app? Storing user addresses and past orders for quicker reordering later? Implementing a loyalty point system?
If in your authentication-less app, you can provide similar features and benefits provided by an authenticated app without compromising much, go for it. Or just cut features and make simplicity your selling point.
By removing adoption friction for one group, you are potentially adding a friction point for another. You’ll have to be the judge on whether it’s worth it.
How about email-only passwordless authentication? Seems like a viable alternative to the username/password. And yeah, keep the social logins as well on top of that.
2) Yeah, that necessity depends on your product.
In what cases or features is authentication needed in a food-ordering app? Storing user addresses and past orders for quicker reordering later? Implementing a loyalty point system?
If in your authentication-less app, you can provide similar features and benefits provided by an authenticated app without compromising much, go for it. Or just cut features and make simplicity your selling point.
I wouldn’t use it. Not interested in outsourcing my identity to another entity - at least not with social login features.
But I’m a minority in that regard.
But I’m a minority in that regard.
Or, maybe, silent majority? :)
> users very likely have Google or Apple accounts
Have neither - therefore assuming I might want to use your app, I could not.
Have neither - therefore assuming I might want to use your app, I could not.
From what you decribe I would skip the registration and use the payment checkout page (e.g. Stripe) to collect all data. It sounds like a new app so first have 100 sales before worrying about more complexity. (In our SaaS startup we dealt with the first 50 sales using email and manual Excel).
Sorry, forgot to add that the app does have some limited adoption/validation using a MVP version of the app. Though I also agree with you and leaning towards "payment-checkout authentication" just so I can release sooner.
However, I was wondering more in general: is there a point at all in having username/password authentication in a mobile app these days, for the reasons i pointed out.
However, I was wondering more in general: is there a point at all in having username/password authentication in a mobile app these days, for the reasons i pointed out.
> is there a point at all in having username/password authentication in a mobile app these days, for the reasons i pointed out.
It depends on your target market. Requiring social media/google/apple accounts in order to use your app means that there will be a lot of people unable or unwilling to use your app.
Whether or not that matters to you is a business decision that only you have enough information to make.
It depends on your target market. Requiring social media/google/apple accounts in order to use your app means that there will be a lot of people unable or unwilling to use your app.
Whether or not that matters to you is a business decision that only you have enough information to make.
It would make sense if you are building a complementary product, that is tied to one of the product of Google, Facebook etc. (For example, an integrated app to google calendar, or a tool for facebook ad management etc.)
For every other purpose, I think you should consider traditional email/password solution. There are good tools for this. I use Keycloak for instance but there are many alternative, self hosted or SaaS.
For every other purpose, I think you should consider traditional email/password solution. There are good tools for this. I use Keycloak for instance but there are many alternative, self hosted or SaaS.
I only implemented Google login in my app. Mainly because I know my target market uses gmail, and they're mostly doctors/health professionals who does not have time to enter password/maintain their own password. They have gmail and want to get things done. But I'm lucky I'm in a small niche
To answer point 1: Maybe to start out, but in the long run, having only social logins may cause your app to lose a segment of the market (I don't know how much). If you're fine with that, then by all means only support social logins.
However, I strongly suggest having it (or some way for someone not to use a social provider) if you want to have as many users a possible.
Personally, I don't have a google account, I'm wary to use my Apple account for non-Apple sites, and I don't have facebook, instagram, new gen z hotness app, etc... And I can confidently say I am not alone in choosing to use apps which don't require a social login.
At the end of the day though, password auth isn't a non-trivial problem. It is a solved problem of which there are numerous articles/papers and many libraries for most languages/frameworks. For example, the Phoenix framework for Elixir has a built in command which scaffolds auth, and it works really well (I have used it in a personal project): https://hexdocs.pm/phoenix/mix_phx_gen_auth.html. For JS, you can use something like passport: https://www.passportjs.org/packages/passport-local/. If you want a separate service entirely (even though it would be more complex to have a separate service to start out), there is GoTrue: https://github.com/netlify/gotrue. These are just a few suggestions of tech I have come across. There is so much more out there, I encourage you to research options to see what may be a best fit.
If you're worried about password auth, maybe give one time passwords a try. They don't require any password reset flow, and are generally secure when implemented correctly. As an example, I don't have a password for my craigslist account. Every time I want to login, I can choose to get a magic link/otp which gets exchanged for a session. In practice (and this is my personal opinion), I prefer magic links. They are one time, hard to guess (again dependent on implementation), can be time limited, and most likely won't be intercepted in transit (though it could be in a rare circumstance).
---
To answer point 2: yes.
If your app is to order things (I use things in a general term) it sounds like eCommerce. And if you're in eCommerce, you better have a way for a user to track what they have ordered and how much they have paid for it at a minimum. Otherwise, your site may come across as a scam, even though it uses Stripe. Sketchy sites can use Stripe to get your money (albeit, it'll be a one time payment).
---
In conclusion, auth for your application seems crucial. Email/password auth is still relevant for applications. While not necessary for an MVP, there is a segment of the market you will lose if you don't have an email/password option, or even an email/OTP/magic link option (I don't know how much, really going off an educated guess).
Best of wishes in building your app! I genuinely hope it is successful and safe for people to leverage :)
--- Edit 1: You may not need auth after all.
After thinking a bit more about some UX from different ordering services (i.e. airlines, doordash). Maybe a way to circumvent is to send that order number w/ an order summary via email, which of course you have stored in your db. You may still need to store an email (depending on the complexity of an order number), but it wouldn't require a full on auth solution to start out with.
It would make my points above moot, and may be lowest friction way for you to get your app off the ground while still giving a user the ability to have access to their orders/order history.
However, I strongly suggest having it (or some way for someone not to use a social provider) if you want to have as many users a possible.
Personally, I don't have a google account, I'm wary to use my Apple account for non-Apple sites, and I don't have facebook, instagram, new gen z hotness app, etc... And I can confidently say I am not alone in choosing to use apps which don't require a social login.
At the end of the day though, password auth isn't a non-trivial problem. It is a solved problem of which there are numerous articles/papers and many libraries for most languages/frameworks. For example, the Phoenix framework for Elixir has a built in command which scaffolds auth, and it works really well (I have used it in a personal project): https://hexdocs.pm/phoenix/mix_phx_gen_auth.html. For JS, you can use something like passport: https://www.passportjs.org/packages/passport-local/. If you want a separate service entirely (even though it would be more complex to have a separate service to start out), there is GoTrue: https://github.com/netlify/gotrue. These are just a few suggestions of tech I have come across. There is so much more out there, I encourage you to research options to see what may be a best fit.
If you're worried about password auth, maybe give one time passwords a try. They don't require any password reset flow, and are generally secure when implemented correctly. As an example, I don't have a password for my craigslist account. Every time I want to login, I can choose to get a magic link/otp which gets exchanged for a session. In practice (and this is my personal opinion), I prefer magic links. They are one time, hard to guess (again dependent on implementation), can be time limited, and most likely won't be intercepted in transit (though it could be in a rare circumstance).
---
To answer point 2: yes.
If your app is to order things (I use things in a general term) it sounds like eCommerce. And if you're in eCommerce, you better have a way for a user to track what they have ordered and how much they have paid for it at a minimum. Otherwise, your site may come across as a scam, even though it uses Stripe. Sketchy sites can use Stripe to get your money (albeit, it'll be a one time payment).
---
In conclusion, auth for your application seems crucial. Email/password auth is still relevant for applications. While not necessary for an MVP, there is a segment of the market you will lose if you don't have an email/password option, or even an email/OTP/magic link option (I don't know how much, really going off an educated guess).
Best of wishes in building your app! I genuinely hope it is successful and safe for people to leverage :)
--- Edit 1: You may not need auth after all.
After thinking a bit more about some UX from different ordering services (i.e. airlines, doordash). Maybe a way to circumvent is to send that order number w/ an order summary via email, which of course you have stored in your db. You may still need to store an email (depending on the complexity of an order number), but it wouldn't require a full on auth solution to start out with.
It would make my points above moot, and may be lowest friction way for you to get your app off the ground while still giving a user the ability to have access to their orders/order history.
1) In 2022, can I offer only social login with Google/Apple/Facebook? (In other words, no traditional username/password based authentication.)
My reasoning: a) The app is US-focused and users very likely have Google or Apple accounts. (Maybe I can add a few other providers for tourists/etc.) b) Having to think of a password for yet-another app adds friction to adoption. c) Password managers may or may not work in an app. d) Implementing password auth (as well as registration, password-reset/etc) is not trivial. e) And, obviously, password authentication have many well documented problems.
2) Do I need to authenticate users at all?
When my user places an order, they will go through a secure payment-portal-hosted iframe from Stripe or similar payment processor. It doesn't seem necessary to have them authenticated through our own system as well.
Having users authenticated to our system would be better for analytics/tracking, but it seems regular tracking technology based on cookies/etc would be a close approximation.
More about my app:
The main workflow is typical: you open the app, search for deals and you order through the app. It is being developed as a hybrid-web application using Ionic (I know ionic isn't the most popular choice but I don't have too much choice, so please forgive me), so it can be used both as an app from the App Store or as a regular web app.