The thing is, that's not just a technical decision. There are strategy, product, and operational reasons why you might decide to add or avoid SSO. SSO for sign-on can be really complicated and have lots of caveats -- for example, Apple requires any app with any SSO option to also support sign in with Apple, or be removed from the app store. Or you may want to restrict certain SSO to enterprise customers only, as a feature, but not have any of them yet. Or your users might have privacy concerns about SSO, or not have accounts at your SSO providers.

Any of these things may or may not be relevant to your decision, and I know that authentication is a specific example within a larger point. What I'm trying to say is that it's never correct to say "<x> is the right approach for all <y> trying to do <z>". Every decision has consequences, and what really matters is your ability to foresee those consequences and weigh them against the broader strategic picture of what you're trying to accomplish.

I think this was an example based on the op example.

Assuming that Google or Facebook or Github has implemented a library correctly, and that it will remain available as long as you want your app to function is dangerous.

As opposed to assuming that you'll implement it correctly when Google or Facebook or github haven't?

Yes, because what's good for them is not necessarily what's good for you.