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.
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.
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.
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.
But I’m a minority in that regard.
Have neither - therefore assuming I might want to use your app, I could not.
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.
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.