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.
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.
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.
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.
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)
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?
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.
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.
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.
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.
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)
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.
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
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?
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.
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.
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.
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.
>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.
