Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

Third-party identity providers are bad for a number of reasons. My biggest issue is that none of the mentioned services make any guarantees against arbitrary account termination or lockdown. If the identity provider decides to lock you out, there's no recourse for the user. Google Accounts are notorious for this, making it nigh impossible to reach a human unless you have an engineering connection on the inside.

This post is a blatant ad for Firebase Auth. Why isn't there any mention of competing services like Auth0 and okta?

There's also lots of frameworks and libraries which handle everything for you with minimal effort. For example, you could setup something like Apache Shiro [0] as an independent service which you call out to from your app. I've seen a few different alternatives in this space, although I can't remember their names off the top of my head. They're usually written in Java, presumably because getting these features right is important for some enterprises.

[0] http://shiro.apache.org/

I think it USED to be hard to reach a person at Google, but over the past year, for a number of various reasons I've needed to reach Google, and I've spoken with a very helpful person in every case I had, it was pretty awesome actually.

How did you get your contact?

Well, that depends on what you need support for. Are you a company giving google lots of money? Their more professional products, like Gsuite and GCP, have support available: https://gsuite.google.com/support/ and https://cloud.google.com/support/?options=premium-support#op...

You're going to have trouble if you're trying to get support for free services (or cheap consumer services) though. Support ain't cheap, and ads aren't going to pay for that.

> USED

FOR YOU

Please don't post unsubstantive comments here.

What if you use third party auth, but keep your own account records, including email addresses?

Then if you run into any issues with the third-party provider, you just "disable" the integration and do a normal email-based password reset flow.

That could be a viable path for some services. It really depends on the use-case, e.g. the kind of information being stored and how it's used.

You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services. Regular account access is allowed after authenticating through any available method, but administrative actions require going through the email flow. That way you reduce the risk from a compromised or malicious third-party. Of course, this would assume that email is a good identification authority, which isn't always the case.

You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services.

You don't need that complex workflow; most third-party authentication services allow you to also request the user's email address during the initial process.

That's fine if you're prepared to trust them as a kind of root authority. But it's not always appropriate. By sending an email and having the user visit the activation link you confirm with fairly high certainty that they are in possession of the email being used.

I don't think some of these alleged identity providers should have as much power and trust as they have.

All you're trusting is that they have verified the email themselves. You still get the email address and can then communicate with and authorize the user directly if you wish.

+1. It's a good idea to have some way of contacting your users regardless of what authentication scheme(s) you use.

Hence the additional suggestion to

4. Allow multiple identities to link to a single user account

Reply on news.ycombinator.com