Hosting is fungible and should be easy to change, a reliance on a platform like FB or Twitter say is not.

Also, reliability is one factor out of several, it is not the only, or even the primary, risk with using something like FB login.

Sure, but the more external components you tie in to the bigger the chance that one of them will be down. So you try to keep such dependencies to an absolute minimum otherwise you end up with the joint downtime of all those services.

External dependencies increase failure points, no argue there.

It depends on your line of business, but if you compare the benefits of making user signup faster, lowering acquisition barriers and getting access to the social graph of users against the risks of depending on one of the top infrastructures in the cloud, I think it may well be worth the trouble.

No, that's not how risk works. Centralization of services to a single platform is more risky.

Your risk increases with more moving parts that you introduce into your product. It does not decrease.

Probably you are talking about redundancy where, I agree, it does go down.

You're both right, if you talk about different sorts of risk. There's far more chance that you'll get authentication wrong than Facebook -- and that's a risk. It's probably more likely that your authentication service will go down than Facebook's. But if it's all yours then Facebook has no control over you, so that's one less risk.

As for which risk is the most important risk, well, that's up to your business to decide. But nothing is without risk, all you can do is choose which to expose yourself to.

(S)he's talking about if you rely on an API/Third Party service over hosting.

You can packup your application and move it to Amazon/Rackspace/DigitalOcean, but if you use Facebook login exclusively or use a third party API for a core service and they decide to change (as GP suggests), you're fucked.