Hacker News Reader

Comment by teeray | Hacker News Reader

What really grinds my gears about OAuth is when there’s 5 providers, plus an email signup, and I forgot which one I used last time. Then I end up creating a new account accidentally, sometimes with no way to retrieve the old one.

View on HN

The simple solution is to do email signup in my opinion.

I don't want to be beholden to oauth providers for my account. A lot of services that provide OAuth signup/signin do it in a way that locks you out of the account if you can't use the OAuth provider anymore.

PSA: you can often "upgrade" to email/password auth on sites that support it by doing a normal "forgot password" flow with the same email address as your OAuth account.

Sometimes. It depends on how they bind your account. On the projects I’ve worked on, we’d always “upgrade” but I’ve seen plenty of sites that just create a new account. A behavior I find very annoying.

I have noticed a trend in many sites to reduce the number of social signin options down to maybe google (for android) and apple (for iOS) plus email / password. I suspect the “which signin method did I use” is one of the main reasons. That and clutter reduction.

By the way one of the big reasons a site might push you toward social signin is because those accounts are usually already verified. When you run through your own email / password flow you need to verify the email yourself (if that is important to your product). It’s an extra step that doesn’t need to happen when you click the magic google / apple button.

Key word is "often", I have heard too many stories where that is not the case.

That is the beauty of password managers these days: I can manage a separate password for everything and it syncs to all my computers.

Plus by using a password manager I give the big players less ability to track me. (they still track me, but I'm not logged into them in the tab they are tracking which leaves some doubt for their algorithms)

I don't remember exactly what happened but I initially created my Spotify account with an email, but then I became linked to my Facebook account, so my Spotify data (profile pic, name...) were pulled from my Facebook account. And for a few years I wasn't able to break this link, so I was stuck with my Facebook account, even though I wanted to get rid of it. Then one day, I was able to transform back my Spotify account to an email one, and I deleted my Facebook account.

I had several exchanges with Spotify support which where basically useless. Basically it was something like, because I used the same email address for both accounts, they automatically made the link.

Now I always use email login and I used + aliases, not only to avoid that mess but obviously better track data leak/sellers.

I'm in the exact same boat right now. I'm too lazy to fix it, so this is basically the only reason I still have my FB account.

Sounds like a win from a product perspective, higher retention! Clearly a feature, not a bug. The metrics don’t lie! /s

Disclosure, I work in this space, for a company called FusionAuth.

> I don't want to be beholden to oauth providers for my account.

And which email provider are you using? You rely on them too, right? If you use a free email provider like Gmail or others, you are relying on them.

Personally I'm a big fan of letting someone log in any which way they want.

OAuth (or federated login if we're being precise) decreases friction.

Here's a link from Auth0 which references some other links talking about double digit increases in conversions when social login is available: https://auth0.com/blog/how-to-use-social-login-to-drive-your...

If it is a business to business app, and your employer is paying for it, the employer typically want to use their own SAML or OIDC based login system.

It does depend on your user base too. If you are targeting devs, adding login with github is a good idea. For more mass market users, Facebook. If you are in China, you'd be fool not to offer login with WeChat. And so on.

I personally like having email as a backup option and always advocate making it available as a baseline.

>And which email provider are you using? You rely on them too, right? If you use a free email provider like Gmail or others, you are relying on them.

today gmail, next month fastmail, next year self hosted.

once I move off of gmail, all the google oauth stuff breaks. So yea, you might today be beholden to one, but that can easily change

> And which email provider are you using? You rely on them too, right?

Not really, as I use my own domain so can just move that between providers. Exactly because I also don't want to be beholden to a free mail provider either.

> Personally I'm a big fan of letting someone log in any which way they want.

Sure, if people do want to use oauth by all means the should. I just don't think the short term signup convenience outweighs the longer term stuff like:

- annoyances of remembering how you signed up, the initial context I replied to.

- Having a extra service mixed in

- The privacy implications of your oauth provider having a neat list of the services you use.

> Here's a link from Auth0 which references some other links talking about double digit increases in conversions when social login is available: https://auth0.com/blog/how-to-use-social-login-to-drive-your...

Not relevant to me as a user ;) I get why companies provide it. I just choose not to for the reasons already mentioned.

I worked around this problem by adding an entry in my password manager with a username of "OAuth: Use Google" or something like that, so I'm informed when I habitually check my browser extension or when I attempt to auto-fill during login.

It's inelegant and could be better, but good enough.

I do the same. I'm happy with it. I thank my past self every time for having the foresight that future self would forget.

1 password does this automatically

If you use a password manager (and my condolences to those who don't), there's really no benefit to using OAuth over an email sign up. It can prepopulate your personal information, but I usually don't want that for the services I sign up for.

There's a couple of services where I prefer to use github for sso because I need them to integrate with data stored there, and it makes sense to me to "bundle" those accounts. But that's very much an edge case.

Is this where I complain about companies that insist I install their MFA app rather than just letting me use Google Authenticator? You're not special.

> there's really no benefit to using OAuth over an email sign up

Except for the really big one, which is strong MFA provided by the identity provider even when the site doesn't support it natively.

I found once I started using a cross-device password manager, I stopped using OAuth anyway!

I don't know about other password managers, but 1Password can track this for you automatically.

1password's browser extension attempts to record this for you.

Agreed, I have seen some sites check the email used and link the account instead of creating a new one. I much prefer this.

On one hand I like that feature – on the other hand it somewhat terrifies me, since it essentially delegates email verification to any of their accepted OAuth providers, unless they make you re-authenticate using your existing credentials, or redo email verification, upon linking the accounts. And not nearly all sites do.

only works with email validation. Sadly some providers don’t do this (not even Microsoft azure ad in some cases…)

Some OAuth users, e.g. from Facebook, don't even have an email address associated with the account. Just a phone number.

Security breach: For a target with a Gmail account, create an account on an unsecured OAuth provider, login to such sites with the unsecured email, access their data because it allows auth with any OAuth provider.

Do any sites allow login from any OAuth provider? How would that even work? Providers need client IDs and client secrets.

The intent was probably "multiple", not "any".

Easily preventable. Ask the user to supply a credential before linking the accounts or only allow account linking if the email is verified at the idp (as someone else noted this is not possible for all idps but for google it is)

If you (the service you are signing up to) use a good auth solution it will prevent that and give you the option to merge the 2 identities (matching on the email address)

sadly most don’t care about how bad their authN is which is mind boggling to me but reality

Is that the right behaviour?

Imagine the following scenario:

An evildoer hacks into my e-mail account, michaelt@example.com, creates a salesforce.com account (with a password). They delete all the e-mails about account creation.

I discover the hack and change the passwords on every account I know about - but I don't know about the salesforce account (in fact I don't have the password to it) so the hacker retains access.

Should the hacker be able to visit gitlab.com, hit the log-in-with-salesforce button, and get access to the michaelt@example.com account?

You have to verify access to the email with a code to do the merge. That solves your issue

But what if the attacker deleted the verification email after they merged the GitLab accounts? Then they still have a backdoor to your GitLab.

As far as I can see you are assuming an attacker with permanent access to your main email account.

If someone has persistent to your main email account you will have all kinds of problems.

As somebody else said, once your email is compromised you are fucked and have far larger problems than a single individual site.

I agree sibling comments are not quite correct about persistent email access. You could fix the email problem while the "backdoor" to Gitlab remains.

The problem statement says this about corrective action:

>I discover the hack and change the passwords on every account I know about

In actuality, the corrective action is to change the passwords and revoke any SSO integrations.

To the original point, this does add more overhead to the process, probably isn't obvious to most people, and depends on the site having clear UI for the topic.

If the attacker has hacked your email then they could presumably do a reset flow on gitlab and reset the password and clear any evidence. The identity provider step is unnecessary. If we assume that linking the salesforce account to gitlab generates an email. Then unless the attacker has persistent access to the email account you’d know about it. If they have persistent access then the existence of the linked account doesn’t matter. They can just do password resets whenever. This does assume linking an account generates an email. MFA or forced authentication with existing account to link a new identity provider makes sense. But in terms of password reset a hacked email is pretty much the keys to the kingdom anyway.

I suppose the slight difference is that with the password reset flow you’d know that you couldn’t login. But nine times out of ten I’d imagine you’d just do your own password reset upon finding you couldn’t login.

No. No. God no. Do not ever do that.

The email address you get from an oauth provider should never be trusted.

Mostly but not entirely true. If Google oauth gives you an @gmail.com email, you can trust it.

A more accurate formulation would be: the email address you get from an oauth provide must not be trusted unless the oauth provider controls the email domain and guarantees no re-use of addresses.

Not that it’s practical to special case every such provider, but with Gmail handling 25% of email, there can be good UX affordances for them a few others.

Even in the case of gmail, which is the best case, you can not be sure the person in control of the Google account is the same as the one that used that gmail address to create an account on your site. The person might have got their Google account hacked, they might have used a shared gmail account to sign up, your service might not have been properly verifying email addresses when they signed up, etc.

But yes, to be fair, if you have email-based password reset functionality, it is not really an additional security vulnerability.

Control of the Gmail account and ability to get an oath token for that account are one at the same, as far as I know. Both indicate you’ve authenticated as that user with Google.

There are a few others. I’m not sure it’s worth the special casing, but it can be a better user experience.

'Never' is a bit strong. It depends a lot on what you're using the email address for. And it's probably safe to trust gmail addresses coming from google, for instance.

What I did, was write logic to link accounts together via an automatic email confirmation.

Try visiting this URL twice, but use two different login methods (that use the same address).

https://auth.ai.moda/pages/v1.0.0/login

I've encountered a Matrix server/Element client that doesn't always present the same options for providers, making it very difficult to log in on a second machine.

this is why Matrix is switching to native OIDC rather than the current messy mix: https://areweoidcyet.com

>What really grinds my gears about OAuth is when there’s 5 providers, plus an email signup, and I forgot which one I used last time.

Yeah there are a couple of sites where I do the login with google, but most of the time I go through the steps of making a real account specifically because of this issue. There should be a way to tell if you already have an oauth account without it just making you a new account if you choose the wrong method.

Reply on news.ycombinator.com