It's madness to me that people (not OP specifically) will simultaneously say "you have to outsource login to a third party, storing passwords safely is too hard" and... also this.
The answer to "what can I do" is "stop depending on a third party service that's critical for your business and essentially trivial to replace".
also as a consumer, don’t use big tech single sign on. If big tech 86s the account for whatever reason, then you lose access to the services you linked the account to.
If handling a user identifier and a hashed password securely, and providing a means to reset said password is more than "trivial" relative to the rest of a business application, the whole scenario is moot anyway because it's going to be shut down before anyone who might attack it is even aware it existed: there isn't really a profitable market for hello-world and "my first todo" apps.
IIRC a basic oauth social login implementation is ~40 lines of code (assuming you already have things like json parsing). You need to understand what you're doing to make sure you do the necessary validation (e.g. including the nonce from OP), but the part auth0 is doing for you is pretty trivial.
How so? Google is an IdP. It provides the user's identity. Auth0 is a middle layer that (in this case) transforms oauth responses into oauth responses.
The thing you'd replace Google with would be something like oauth client auto-registration so people can use their own oauth server on their domain.
Edit: Oh, I see what you/they mean. That's probably fair, but SSO is actually convenient for people, so it's fair to offer both oauth and user/password login. And dealing with SSO is probably easier than handling passwords, reset flows, etc. Passkeys would also work well here if they weren't so user-hostile.
> dealing with SSO is probably easier than handling passwords, reset flows, etc.
It's really not that difficult. Yes you need to be aware of risks, and be more careful with the data. But it's not exactly rocket science, and you're never going to end up in a scenario where your users can't login because the login flow is out of your hands, as per the topic of this thread.
> you're never going to end up in a scenario where your users can't login because the login flow is out of your hands
It's more likely that the person re-implementing the SSO flow is making a mistake and the login behaviour is getting messed up than the default Google/Apple SSO implementation that's deployed to billions of users and business critical for many companies that use that kind of SSO internally too.
> It's more likely that the person re-implementing the SSO flow is making a mistake
The thread has other people confirming the same behaviour - and the description of the issue (preventing a double-submit of a non-idempotent action) is something most web-focused developers learn in their first year.
I don't understand why people assume that the people working at Google/etc are inherently incapable of producing bugs. Go literally invented a new programming language to make their staff less likely to fuck up because they don't have much real world experience: https://www.youtube.com/watch?v=uwajp0g-bY4
Taking HN thread replies or users as a sample for anything is almost never a good idea.
Even in this thread there's a split between people who can replicate it and people who can't, so it's more likely an edge case and not a global issue affecting all Google SSO implementations.
> Even in this thread there's a split between people who can replicate it and people who can't
I don't think "even the buggy behaviour is not reliably reproducible" is really the selling point you should be touting, if your claim is that Google "does it better".
I can't reply below yours, so I'll add this:
> The point is that globally rolled out solution that billions of users use every day and companies depend on is obviously better tested, better monitored, fixed quicker, more accessible than a one-off handcrafted solution for most use cases and companies where that is not their core competency.
None of those things are obvious, and the original topic of this is from the context of a software developer, that also offers their own direct "email + password" sign in option, so clearly the monumental task of storing a password, and offering password resets is not too much for them.
Your claim that large companies do things "better, obviously" is honestly laughable.
The point is that globally rolled out solution that billions of users use every day and companies depend on is obviously better tested, better monitored, fixed quicker, more accessible than a one-off handcrafted solution for most use cases and companies where that is not their core competency.
The answer to "what can I do" is "stop depending on a third party service that's critical for your business and essentially trivial to replace".