> Additionally, registering and configuring your app at Apple / Facebook / Google etc. is non-trivial. I know what I am doing in theory, and I have already invested a week of time in configuration and approvals and updates.
I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work. Maybe the case could be made for day-1 of a startup, but certainly not year-1, it's just too critical a component.
I'd also challenge this taking a week. Apple/FB/Google sign-on is pretty straightforward, and I've found the cost is mostly in setting up an open-source auth library in my webapps rather than enabling a given service provider.
> I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work. Maybe the case could be made for day-1 of a startup, but certainly not year-1, it's just too critical a component.
Are you not outsourcing to an intermediary with Apple/FB/Google?
Authentication is critical. Completely agree. It is also not a differentiator for your application unless done poorly. Using a 3P such as Apple/FB/Google leverages the account protection investment that those providers are making. Using Hellō gives the same protection, while preserving the user's privacy (provider does not know which app the user is logging into) -- and giving them choice and account recovery.
As noted, if you have already made the investment, Hellō does not provide the same value today.
> I'd also challenge this taking a week. Apple/FB/Google sign-on is pretty straightforward, and I've found the cost is mostly in setting up an open-source auth library in my webapps rather than enabling a given service provider.
I'm sharing my experience. Apple requires a D&B number to register your app. Many require you to jump through their process for proving control of a domain. Microsoft requires you register as a partner if you don't want the scary unverified label. FB disabled Hellō for not having the correct link to the app, then disabled for not having a required term in our T&S.
Others may not have the same challenges as I did -- but it was non-trivial amount of time to manage the app registrations.
FWIW I don't use libraries for the OIDC flows -- I find it makes it more complicated than it needs to be. I do use libraries for any JWT work of course.
I concur that some of the tier0 social login providers are not very developer friendly. The more dev friendly and user friendly social logins are such as GitHub or Discord. They have straight forward processes and a clear management console.
> Are you not outsourcing to an intermediary with Apple/FB/Google?
This is a product decision, it gets you better security (on average), brand association that may be good for the right product/SSO combination, easier signup (at least in theory), and in many cases is necessary for integrations with those services.
Using Hellō gets you better security (on average), but not as much as going direct. It loses some of the brand association, and in fact I'd suggest many users would probably want to whitelabel Hellō. It adds an extra step to sign-up over direct integrations. And it likely complicates integrations with the services.
> I'm sharing my experience. Apple requires a D&B number to register your app. Many require you to jump through their process for proving control of a domain. Microsoft requires you register as a partner if you don't want the scary unverified label. FB disabled Hellō for not having the correct link to the app, then disabled for not having a required term in our T&S.
Facebook will ban apps for all sorts of reasons, but having experienced the nasty end of this I unfortunately suspect that Facebook might take issue with it, and Hellō may become a single point of failure that could cause a FB login outage across many services.
> FWIW I don't use libraries for the OIDC flows -- I find it makes it more complicated than it needs to be. I do use libraries for any JWT work of course.
I've seen good ones and bad ones. The one that I was thinking of when I wrote my original comment was Django All Auth. It gives you much the same effect as Hellō, and in my experience setup of the library has not been difficult, and has made it easier to implement multiple flows quickly. Devise for Rails was a bit of a pain 9 years ago though.
It probably all depends on access to high quality libraries in your ecosystem of choice how much you value things like Hellō, and having a lot of Django experience I just don't really feel the value proposition.
As a developer, you don't know which provider the user has chosen, and the provider does not know which apps the user is using, improving privacy and resiliency.
> And it likely complicates integrations with the services.
If you want access to resources at the provider, such as Google Calendar, then you will need to directly integrate to get the access token. Hellō provides identity, not access to resources.
> I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work.
The market is tested, though. Auth0 is a notable player in this space and they seem to be making money.
Like you, I've been pretty unhappy with this class of product. Auth0 provides just enough to be dangerous; upload Javascript with no way to unit test it to gate auth (that broke!), support for multiple social providers but no built-in way to unify accounts (do that yourself), etc. They also have an insanely low limit for OAuth client applications; so low that we had to buy an enterprise contract to scale out to production.
(BTW, the way I tested auth hooks after an outage caused by a faulty one was to implement their API in Go, embed a Javascript interpreter in our Go tests, and then execute the hooks against an in-memory version of our API server. That eliminated any server-caused auth hook breakages. But I have to ask, why am I paying them when I have to do all the work?)
Auth0 can be prohibitively expensive if you have low revenue per user.
We are working on providing an OSS docker image that would mock Hellō so that you could get full coverage in automated testing of registration and login. Would you find that useful?
I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work. Maybe the case could be made for day-1 of a startup, but certainly not year-1, it's just too critical a component.
I'd also challenge this taking a week. Apple/FB/Google sign-on is pretty straightforward, and I've found the cost is mostly in setting up an open-source auth library in my webapps rather than enabling a given service provider.